Thread: exit() calls in libraries

Debian's package policy and quality check tool lintian reports the
following (among other things) on the postgresql-9.1 (and earlier)
packages:

X: libpq5: shlib-calls-exit usr/lib/libpq.so.5.4
X: libecpg6: shlib-calls-exit usr/lib/libecpg.so.6.3

which is explained as

I: shlib-calls-exit
N:
N:   The listed shared library calls the C library exit() or _exit()
N:   functions.
N:   
N:   In the case of an error, the library should instead return an
N:   appropriate error code to the calling program which can then determine
N:   how to handle the error, including performing any required clean-up.
[snip]

The report on libecpg is actually a false positive, because the exit()
call comes from get_progname() in path.c, which is not called from
functions in libecpg.

The cases in libpq are
     * various places in fe-print.c calling exit(1) when malloc fails,       presumably having run out of memory, and
 * in libpq-int.h the macro PGTHREAD_ERROR, which is called in       several places in fe-connect.c and fe-secure.c.
 

Are these appropriate behaviors?  The fe-print.c stuff probably isn't
used much anymore.  But the threading stuff is, and it encroaches on the
exit status space of the libpq-using program.  And does it even make
sense to call exit() if the thread locking is busted?  Maybe abort()
would work better?

Excerpts from Peter Eisentraut's message of lun dic 05 14:27:41 -0300 2011:

> The cases in libpq are
>
>       * various places in fe-print.c calling exit(1) when malloc fails,
>         presumably having run out of memory, and
>       * in libpq-int.h the macro PGTHREAD_ERROR, which is called in
>         several places in fe-connect.c and fe-secure.c.
>
> Are these appropriate behaviors?  The fe-print.c stuff probably isn't
> used much anymore.  But the threading stuff is, and it encroaches on the
> exit status space of the libpq-using program.  And does it even make
> sense to call exit() if the thread locking is busted?  Maybe abort()
> would work better?

Having had to battle some exit() calls in the PHP interpreter back when
I was working in PL/php, I agree that they shouldn't be there -- abort()
seems more appropriate if the system is truly busted.  As for the
fr-print.c code, I'm not really sure why don't we just remove it.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On mån, 2011-12-05 at 15:04 -0300, Alvaro Herrera wrote:
> Having had to battle some exit() calls in the PHP interpreter back
> when
> I was working in PL/php, I agree that they shouldn't be there --
> abort()
> seems more appropriate if the system is truly busted.  As for the
> fr-print.c code, I'm not really sure why don't we just remove it.
>
This is the patch that would get rid of all exit() calls in the
libraries.