Re: Automatic PG_PRINTF_ATTRIBUTE
От | Tom Lane |
---|---|
Тема | Re: Automatic PG_PRINTF_ATTRIBUTE |
Дата | |
Msg-id | 17877.1416593785@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Automatic PG_PRINTF_ATTRIBUTE (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: Automatic PG_PRINTF_ATTRIBUTE
|
Список | pgsql-hackers |
Noah Misch <noah@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. What about the MSVC build path? I guess there we're only targeting one compiler, so it should be easy. regards, tom lane
В списке pgsql-hackers по дате отправления: