Re: shlib-calls-exit and the flex-generated function yy_fatal_error
"Bernhard R. Link" <brlink@debian.org> writes:
> * Russ Allbery <rra@debian.org> [121102 19:29]:
>> I'm starting to think that we should drop this tag entirely. There are
>> a lot of legitimate reasons why shared libraries call exit(), plus
>> there are legitimate reasons why shared library source includes a call
>> to exit() that isn't reachable (something that Lintian cannot detect),
>> such as this one.
> Is this actually not reachable? This quite looks like a true-positive
> (only taking into account what was written in this thread, without
> looking at the actual code).
Ah, yes, I'd missed that; it's called for some internal error conditions.
It doesn't apparently apply to this case, but I personally have other
cases where the code is unreachable, so I know it's an issue.
Unfortunately, the linker tends not to discard code when building shared
libraries, even if that code is not used anywhere in the shared library.
So, for example, I have a common utility library for handling error
reporting that I use in some shared libraries as well as in programs. One
of its functions, used by programs but not by shared libraries, calls
exit. If that library is included in a shared library, even if all its
symbols are marked as hidden/internal for the compiler and those functions
are never called, and even if those functions are isolated in a separate
*.o file that is never used by any other shared library call, it ends up
included in the shared library anyway and triggers this tag. This sort of
thing happens when one has a utility library using libtool that gets
linked into both a shared library and into executables, but isn't part of
the public API of the shared library.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: