]> granicus.if.org Git - postgresql/commit
Distinguish printf-like functions that support %m from those that don't.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 11 Aug 2018 15:11:05 +0000 (11:11 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 11 Aug 2018 15:11:05 +0000 (11:11 -0400)
commit3a60c8ff892a8242b907f44702bfd9f1ff877d45
tree55e236a214db96aa70997a72e62decaa504d0bfe
parent5c047fd709ae274d5d543b250c70cc2b15e4fe65
Distinguish printf-like functions that support %m from those that don't.

The elog/ereport family of functions certainly support the %m format spec,
because they implement it "by hand".  But elsewhere we have printf wrappers
that might or might not allow it depending on whether the platform's printf
does.  (Most non-glibc versions don't, and notably, src/port/snprintf.c
doesn't.)  Hence, rather than using the gnu_printf format archetype
interchangeably for all these functions, use it only for elog/ereport.
This will allow us to get compiler warnings for mistakes like the ones
fixed in commit a13b47a59, at least on platforms where printf doesn't
take %m and gcc is correctly configured to know it.  (Unfortunately,
that won't happen on Linux, nor on macOS according to my testing.
It remains to be seen what the buildfarm's gcc-on-Windows animals will
think of this, but we may well have to rely on less-popular platforms
to warn us about unportable code of this kind.)

Discussion: https://postgr.es/m/2975.1526862605@sss.pgh.pa.us
config/c-compiler.m4
configure
src/include/c.h
src/include/pg_config.h.in
src/include/utils/elog.h