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.
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 |