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  (Noah Misch <noah@leadboat.com>)
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: pg_multixact not getting truncated
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: pg_multixact not getting truncated