Re: Preventing abort() and exit() calls in libpq - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Preventing abort() and exit() calls in libpq
Date
Msg-id 20210703214658.GA2421985@rfd.leadboat.com
Whole thread Raw
In response to Re: Preventing abort() and exit() calls in libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Preventing abort() and exit() calls in libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Jul 03, 2021 at 10:45:59AM -0400, Tom Lane wrote:
> I'd imagined leaving, e.g., psprintf.c out of libpgcommon_shlib.a.
> But if someone mistakenly introduced a psprintf call into libpq,
> it'd still compile just fine; the symbol would be resolved against
> psprintf in the calling application's code.

I think that would fail to compile on Windows, where such references need
exported symbols.  We don't make an exports file for applications other than
postgres.exe.  So the strategy that inspired this may work.

> What I'm now thinking about is restricting the test to only be run on
> platforms where use of foo.a libraries is deprecated, so that we can
> be pretty sure that we won't hit this situation.  Even if we only
> run the test on Linux, that'd be plenty to catch any mistakes.

Hmm.  Static libraries are the rarer case on both AIX and Linux, but I'm not
aware of a relevant deprecation on either platform.  If it comes this to, I'd
be more inclined to control the Makefile rule with an environment variable
(e.g. ENFORCE_LIBC_CALL_RESTRICTIONS) instead of reacting to the platform.



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Unbounded %s in sscanf
Next
From: Tom Lane
Date:
Subject: Re: Preventing abort() and exit() calls in libpq