Warning: shared-lib-calls-exit detected by a lint tool

[junaruga]

Thanks for maintaining this software. When checking a htslib 1.13 RPM package on Fedora by a lint tool called rpmlint, the following warning was detected. I am not sure how important it is. But I would just report it here.

htslib.x86_64: W: shared-lib-calls-exit /usr/lib64/libhts.so.1.13 exit@GLIBC_2.2.5
This library package calls exit() or _exit(), probably in a non-fork()
context. Doing so from a library is strongly discouraged - when a library
function calls exit(), it prevents the calling program from handling the 
error, reporting it to the user, closing files properly, and cleaning up any 
state that the program has. It is preferred for the library to return an
actual error code and let the calling program decide how to handle the 
situation.

[jkbonfield]

It's true there are calls to exit in some of the VCF and BCF code when it meets corrupted data, which I fully agree isn't appropriate for a library. Eg in bcf_get_format_values(). This is an issue due to the legacy of the code, originating in command line tools before they made their way into a library.

Although I'm also unsure how problematic this is in the wild. We've addressed the ones that occur in common scenarios and some of these may even be impossible to reach now, but we ought to tidy up the remainder.

We'll probably find it hard to remove every single one though without breaking the ABI as some are tied to memory reallocation in functions that have no return value. That is, clearly, a bad design decision in the original implementation. Completely running out of memory though isn't something which the calling application is likely to recover from. Technically we should return an error code, but realistically that's just shifting the exit call to the application instead. So the priority isn't high on that front.