Re: Preventing abort() and exit() calls in libpq
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
Michael Paquier <michael@paquier.xyz>,
Jacob Champion <pchampion@vmware.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Daniel Gustafsson <daniel@yesql.se>, info@cspug.cz
Date: 2021-07-03T14:45:59Z
Lists: pgsql-hackers
I wrote: > I'm now wondering about applying the test to *.o in libpq, > as well as libpgport_shlib.a and libpgcommon_shlib.a. > The latter would require some code changes, and it would make > the prohibition extend further than libpq alone. On the bright > side, we could reinstate the check for abort(). After consuming a bit more caffeine, I'm afraid that won't work. 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. We'd only detect a failure when trying to use libpq with an app that didn't contain that function, which feels like something that our own testing could miss. 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. regards, tom lane
Commits
-
Further restrict the scope of no-exit()-in-libpq test.
- 792259591c0f 15.0 landed
-
Improve build-time check that libpq doesn't call exit().
- 2f7bae2f924d 15.0 landed
-
Fix portability fallout from commit dc227eb82.
- e45b0dfa1f10 15.0 landed
-
Add a build-time check that libpq doesn't call exit() or abort().
- dc227eb82ea8 15.0 landed