]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Use libc's snprintf, not sprintf, for special cases in snprintf.c.
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 16 Oct 2022 15:47:44 +0000 (11:47 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 16 Oct 2022 15:47:44 +0000 (11:47 -0400)
commitbd4b2926ecc25b4435f816ce4ec542d9a01cdb09
tree64bd5251787f516cc9be1667e6abcbc0f47ef524
parent16d11d68437a6a37af1fea08d4a29ef463f0d62c
Use libc's snprintf, not sprintf, for special cases in snprintf.c.

snprintf.c has always fallen back on libc's *printf implementation
when printing pointers (%p) and floats.  When this code originated,
we were still supporting some platforms that lacked native snprintf,
so we used sprintf for that.  That's not actually unsafe in our usage,
but nonetheless builds on macOS are starting to complain about sprintf
being unconditionally deprecated; and I wouldn't be surprised if other
platforms follow suit.  There seems little reason to believe that any
platform supporting C99 wouldn't have standards-compliant snprintf,
so let's just use that instead to suppress such warnings.

Back-patch to v12, which is where we started to require C99.  It's
also where we started to use our snprintf.c everywhere, so this
wouldn't be enough to suppress the warning in older branches anyway
--- that is, in older branches these aren't necessarily all our
usages of libc's sprintf.  It is enough in v12+ because any
deprecation annotation attached to libc's sprintf won't apply to
pg_sprintf.  (Whether all our usages of pg_sprintf are adequately
safe is not a matter I intend to address here, but perhaps it could
do with some review.)

Per report from Andres Freund and local testing.

Discussion: https://postgr.es/m/20221015211955.q4cwbsfkyk3c4ty3@awork3.anarazel.de
src/port/snprintf.c