This could be triggered by a #CHROM line ending in something like:
#CHROM\t...\tINFO\t\t\t\t\t\t ... many tabs ... \t\t\tfoo\n
Between each pair of tabs, bcf_hdr_add_sample_len() was called with len = 0, as if from bcf_hdr_add_sample(). This made it use strlen(s) instead of 0 as the sample name length, resulting in the addition of a bogus sample name with lots of leading tabs. The sample line parser then moved on to the next tab, and did the same thing again with one fewer leading tab.
Fix by making bcf_hdr_add_sample_len() always use the passed-in length, even if 0, allowing the empty sample name trap to do its work. bcf_hdr_add_sample() is updated to call strlen() itself, and to also deal with the backwards-compatibility check where it was permissible to call it with a NULL string.
This could be triggered by a #CHROM line ending in something like:
Between each pair of tabs,
bcf_hdr_add_sample_len()was called withlen = 0, as if frombcf_hdr_add_sample(). This made it usestrlen(s)instead of 0 as the sample name length, resulting in the addition of a bogus sample name with lots of leading tabs. The sample line parser then moved on to the next tab, and did the same thing again with one fewer leading tab.Fix by making
bcf_hdr_add_sample_len()always use the passed-in length, even if 0, allowing the empty sample name trap to do its work.bcf_hdr_add_sample()is updated to callstrlen()itself, and to also deal with the backwards-compatibility check where it was permissible to call it with a NULL string.