hts_parse_decimal() silently fails on non-numeric strings starting with G

[pd3]

The function does not reject strings like G A, thinking it was able to parse a coordinate due to

htslib/hts.c

Line 3513 in 1c8829a

case 'g': case 'G': e += 9; s++; break;

This leads to problems reported in samtools/bcftools#1598 where region format is autodetected by first attempting to read chr beg end and, upon failure, reads chr pos. One relevant part of code that can be mislead by this is

htslib/synced_bcf_reader.c

Lines 1126 to 1130 in 1c8829a

	if ( k==ifrom )
	*to = hts_parse_decimal(ss, &tmp, 0);
	else
	*from = hts_parse_decimal(ss, &tmp, 0);
	if ( ss==tmp ) return -1;

[jmarshall]

Indeed, it shouldn't be recognising G as 0 gigabases/gigabytes; those suffixes should require some digits first, e.g. 1G.

I think it would be appropriate to only do the E and K/M/G processing if a non-zero number of digits have been seen. Or pretty much equivalently, by wrapping if (s > str) around this processing.

1e+3k doesn't seem good to accept, so I would suggest merging the E/e processing into the switch, so that only one instance of any of E/K/M/G is accepted.

[pd3]

I issued a pull request here #1396.

Although expressions like 1e+3k are ambiguous, (1e3)k vs 1e(3k), I don't mind those as much as they are interpreted the expected way (1e3)k.