Fix hts_idx_get_n_no_coor() out-of-bounds memory access

[jmarshall]

For CRAI-indexed CRAM files, idx actually points to an hts_cram_idx_t — which has no n_no_coor field. Return an appropriate "not available" value instead.

This OOB bug can be observed with valgrind samtools idxstats test/range.cram if you disable the slow method format check:

--- samtools-a/bam_index.c
+++ samtools-b/bam_index.c
@@ -209,7 +209,7 @@ int bam_idxstats(int argc, char *argv[])
-    if (hts_get_format(fp)->format != bam) {
+    if (0 && hts_get_format(fp)->format != bam) {
     slow_method:

It is also observable via pysam: see pysam-developers/pysam#1048.

[jmarshall]

AppVeyor failure heisenbug is due to an unrelated bug in PR #1325's fastq_parse1() changes: in SRA names mode, s[i] is the wrong offset into the string — it reflects the addition of the initial value of i to x->name.s twice. It's amazing it doesn't fail on other platforms too.

IMHO the FASTA/Q name extraction code needs an overhaul, as it doesn't handle the case of spaces before the name, e.g.,

>   name   comment blah blah
ATGC

which is borderline crap, but something that faidx has had to deal with for years (cf samtools/samtools#449). Thus demonstrating that it does exist out in the world.

[daviesrob]

Thanks. A fix for the fastq_name2 problem is now in #1337.