Michael Paquier <mich...@paquier.xyz> writes:
> On Sat, Jun 26, 2021 at 05:29:29PM -0400, Tom Lane wrote:
>> I'll stick this into the CF list to see if the cfbot agrees that
>> it finds the abort() problems...
> The CF Bot is finding those problems.
>> +# Check for functions that libpq must not call.
>> +# (If nm doesn't exist or doesn't work on shlibs, this test will silently
>> +# do nothing, which is fine.)
>> +.PHONY: check-libpq-refs
>> +check-libpq-refs: $(shlib)
>> + @! nm -A -g -u $< 2>/dev/null | grep -e abort -e exit
Yeah, all except on Windows. Not sure if it's worth trying to build
some way to make this check on Windows.
> "abort" and "exit" could be generic terms present in some other
> libraries. Could be be better to match with "U abort" and "U exit"
> instead?
No, for a couple of reasons:
* nm's output format isn't all that well standardized
* on some platforms, what appears here is "_abort".
I would have liked to use "-w" in the grep call, but between the
"_abort" case and the "abort@@GLIBC" case we see elsewhere, we'd
be assuming way too much about what grep will consider to be a word.
In practice I don't think it's too much of a problem. It doesn't
matter whether libc has exported names containing "exit", unless
libpq or something it imports from src/common or src/port actually
attempts to call those names. Which I'm not expecting.
A possible counterexample is atexit(3). If libpq ever grew a
reason to call that then we'd have an issue. It wouldn't be
that hard to work around, by adding a grep -v filter. But in
any case I'm dubious that we could ever make correct use of
atexit(3) in libpq, because we'd have no way to know whether
the host application has its own atexit callbacks and if so
whether they'll run before or after libpq's. Something like
isolationtester's atexit callback to PQclose all its connections
would risk breakage if libpq tried to clean up via atexit.
regards, tom lane
