database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

Revert "Distinguish printf-like functions that support %m from those that don't."

Browse Source 
This reverts commit 3a60c8ff89.  Buildfarm
results show that that caused a whole bunch of new warnings on platforms
where gcc believes the local printf to be non-POSIX-compliant.  This
problem outweighs the hypothetical-anyway possibility of getting warnings
for misuse of %m.  We could use gnu_printf archetype when we've substituted
src/port/snprintf.c, but that brings us right back to the problem of not
getting warnings for %m.

A possible answer is to attack it in the other direction by insisting
that %m support be included in printf's feature set, but that will take
more investigation.  In the meantime, revert the previous change, and
update the comment for PGAC_C_PRINTF_ARCHETYPE to more fully explain
what's going on.

Discussion: https://postgr.es/m/2975.1526862605@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2018-08-12 18:46:01 -04:00
parent d11eae09e4
commit 46b5e7c4b5
5 changed files with 34 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
config/c-compiler.m4
View File

@ -19,12 +19,18 @@ fi])# PGAC_C_SIGNED
# PGAC_C_PRINTF_ARCHETYPE
# -----------------------
# Set the format archetype used by gcc to check elog/ereport functions.
# This should accept %m, whether or not the platform's printf does.
# We use "gnu_printf" if possible, which does that, although in some cases
# it might do more than we could wish.
# Select the format archetype to be used by gcc to check printf-type functions.
# We prefer "gnu_printf", which matches the features glibc supports, notably
# %m, 'z' and 'll' width modifiers ('ll' only matters if int64 requires it),
# and argument order control if we're doing --enable-nls. On platforms where
# the native printf doesn't have 'z'/'ll' or arg control, we replace it with
# src/port/snprintf.c which does, so that the only potential mismatch here is
# whether or not %m is supported. We need that for elog/ereport, so we live
# with the fact that erroneous use of %m in plain printf calls won't be
# detected. (It appears that many versions of gcc/clang wouldn't report it
# even if told to check according to plain printf archetype, anyway.)
AC_DEFUN([PGAC_PRINTF_ARCHETYPE],
[AC_CACHE_CHECK([for printf format archetype for %m], pgac_cv_printf_archetype,
[AC_CACHE_CHECK([for printf format archetype], pgac_cv_printf_archetype,
[ac_save_c_werror_flag=$ac_c_werror_flag
ac_c_werror_flag=yes
AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
@ -34,8 +40,8 @@ __attribute__((format(gnu_printf, 2, 3)));], [])],
[pgac_cv_printf_archetype=gnu_printf],
[pgac_cv_printf_archetype=printf])
ac_c_werror_flag=$ac_save_c_werror_flag])
AC_DEFINE_UNQUOTED([PG_PRINTF_ATTRIBUTE_M], [$pgac_cv_printf_archetype],
[Define as a format archetype that accepts %m, if available, else printf.])
AC_DEFINE_UNQUOTED([PG_PRINTF_ATTRIBUTE], [$pgac_cv_printf_archetype],
[Define to gnu_printf if compiler supports it, else printf.])
])# PGAC_PRINTF_ARCHETYPE