From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Automatic PG_PRINTF_ATTRIBUTE |
Date: | 2014-11-21 18:16:25 |
Message-ID: | 17877.1416593785@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Noah Misch <noah(at)leadboat(dot)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.
What about the MSVC build path? I guess there we're only targeting
one compiler, so it should be easy.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2014-11-21 18:38:27 | Re: Yet another abort-early plan disaster on 9.3 |
Previous Message | Andrew Dunstan | 2014-11-21 18:05:47 | Re: psql \sf doesn't show it's SQL when ECHO_HIDDEN is on |