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 a13b47a5, 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
Showing
Please register or sign in to comment