On Fri, Nov 21, 2014 at 01:16:25PM -0500, Tom Lane wrote: > Noah Misch <n...@leadboat.com> writes: > > pg_config_manual.h has been choosing gnu_printf as the PG_PRINTF_ATTRIBUTE > > for > > every MinGW build. That invites a torrent of warnings on pre-gcc-4.4 MinGW > > compilers, including the compiler on buildfarm member narwhal. I'm > > increasingly using an affected compiler, because it builds twice as quickly > > as > > today's gcc. Let's have "configure" detect whether gcc supports gnu_printf > > before using it. I gather plain "printf" aliases ms_printf on Windows and > > gnu_printf elsewhere. Therefore, while the new "configure" test applies to > > all platforms, non-Windows platforms are disinterested in the outcome today. > > Suppose gcc introduces aix_printf and has plain "printf" alias it on AIX. > > PostgreSQL will continue to replace platform printf implementations that > > depart from our format processing expectations, and our own elog.c code > > processes errmsg() formats. Therefore, gnu_printf would remain the better > > global choice even if new archetypes become available. > > No objection here. I'm not 100% convinced by your argument that we'd not > need to modify the logic in future ... but if we do, we'd still be better > off having it in a configure test than trying to get an #ifdef nest to > do the right thing.
Agreed. The key take-away is that I opted to use gnu_printf on all compilers supporting it, not just on Windows compilers supporting it. > What about the MSVC build path? I guess there we're only targeting > one compiler, so it should be easy. c.h zaps __attribute__(...) under non-__GNUC__ compilers, so we need not touch the MSVC build system. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
