| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> | 
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | exit() calls in libraries | 
| Date: | 2011-12-05 17:27:41 | 
| Message-ID: | 1323106061.10992.9.camel@vanquo.pezone.net | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
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?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-12-05 17:31:10 | Re: [PATCH] Caching for stable expressions with constant arguments v3 | 
| Previous Message | Marti Raudsepp | 2011-12-05 17:16:24 | Re: [PATCH] Caching for stable expressions with constant arguments v3 |