Horton

Re: printf %s with NULL pointer (was Re: BUG #17098: Assert failed on composing an error message when adding a type to an extension being dropped)

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2021-07-13T15:52:06Z
Lists: pgsql-bugs, pgsql-hackers

Attachments

I wrote:
> Now, what we don't have control of is what will happen in pre-v12
> branches on platforms where we use the system's *printf.  However,
> note what I wrote in the log for 0c62356cc:
>     Per commit e748e902d, we appear to have little or no coverage in the
>     buildfarm of machines that will dump core when asked to printf a
>     null string pointer.
> Thus it appears that a large fraction of the world is already either
> using glibc or following glibc's lead on this point.

Further to that point: I just ran around and verified that the system
printf prints "(null)" rather than crashing on FreeBSD 12.2, NetBSD 8.99,
OpenBSD 6.8, macOS 11.4, and Solaris 11.3.  AIX 7.2 and HPUX 10.20 print
"", but still don't crash.  If we change snprintf.c then we will also be
okay on Windows, because we've always used our own snprintf on that
platform.  In short, the only place I can find where there is actually
any hazard is Solaris 10 [1].  I do not think we should let the risk of
obscure bugs in pre-v12 versions on one obsolete OS drive our
decision-making about this.

			regards, tom lane

[1] Per experimentation locally and on the GCC compile farm, using
the attached.

Commits

  1. Make printf("%s", NULL) print "(null)" instead of crashing.

  2. Lock the extension during ALTER EXTENSION ADD/DROP.

  3. Add an assertion that we don't pass NULL to snprintf("%s").

  4. Fix broken logic for reporting PL/Python function names in errcontext.