Re: Preventing abort() and exit() calls in libpq

From: Noah Misch <noah(at)leadboat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Jacob Champion <pchampion(at)vmware(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>, info(at)cspug(dot)cz
Subject: Re: Preventing abort() and exit() calls in libpq
Date: 2021-07-03 21:46:58
Message-ID: 20210703214658.GA2421985@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-07-03 22:44:20 Re: Preventing abort() and exit() calls in libpq
Previous Message Daniel Gustafsson 2021-07-03 20:18:54 Re: Unbounded %s in sscanf