cuneiform team mailing list archive

[JussiP <jpakkane@xxxxxxxxx>]

A quick look seems to indicate that these are all parts of assertion
frameworks that get called when CF's internal state goes horribly wrong.

These functions are called from a gazillion different places so fixing
all code paths is not feasible. Doubly so because CF is a mixture of C
and C++ so you can't just throw an exception and have it clean
everything (at least this is my understanding, feel free to correct me).

Given these limitations, I'm recommending a "fail fast and hard" option,
which in this case is exit().

-- 
shared-lib-calls-exit
https://bugs.launchpad.net/bugs/601373
You received this bug notification because you are a member of Cuneiform
Linux, which is the registrant for Cuneiform for Linux.

Status in Linux port of Cuneiform: New

Bug description:
cuneiform-1.0.0

I build packages for openSUSE. rpmlint warns about  shared-lib-calls-exit.

RPMLINT report:
===============
libcuneiform1.i586: W: shared-lib-calls-exit /usr/lib/liblns32.so.1.0.0 exit@GLIBC_2.0
libcuneiform1.i586: W: shared-lib-calls-exit /usr/lib/libstd32.so.1.0.0 exit@GLIBC_2.0
libcuneiform1.i586: W: shared-lib-calls-exit /usr/lib/librfrmt.so.1.0.0 exit@GLIBC_2.0
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.