`bcf_sr_seek` behaves differently for VCF.gz and BCF about htslib HOT 2 CLOSED

I traced the problem down to

The tbx_readrec() function returns the length of the string on success whereas the corresponding bcf_readrec() returns 0. The iterator then returns this value via hts_itr_next()

Arguably the iterator should behave consistently across all data types.

from htslib.

Continuing with this, it seems that bcf_sr_seek is a wrong solution for the task: bcftools consensus wants to query a region similarly to bcf_sr_set_regions, but on the fly. Instead the function attempts to seek to a contig and if not present, a streaming-like mode is entered based on the order of contigs in the header (BCF) or tabix index. In this mode repeated seeks to a non-existent locations result in different outcome from subsequent bcf_sr_next_line calls.

A desired fix should (1) make repeated seek+next_line calls consistent and (2) provide on-the-fly alternative to bcf_sr_set_regions

from htslib.