diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2018-08-12 18:46:01 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2018-08-12 18:46:01 -0400 |
commit | 46b5e7c4b5befbf6ac86d827a3a58f1f02c7338e (patch) | |
tree | d650f4d3293ec1d27961b17baa7cb5a020a973d7 /config/c-compiler.m4 | |
parent | d11eae09e48694ad6b4139bbb7d7b112833301f5 (diff) | |
download | postgresql-46b5e7c4b5befbf6ac86d827a3a58f1f02c7338e.tar.gz |
Revert "Distinguish printf-like functions that support %m from those that don't."
This reverts commit 3a60c8ff892a8242b907f44702bfd9f1ff877d45. 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
Diffstat (limited to 'config/c-compiler.m4')
-rw-r--r-- | config/c-compiler.m4 | 20 |
1 files changed, 13 insertions, 7 deletions
diff --git a/config/c-compiler.m4 b/config/c-compiler.m4 index dfcc1c6600..67675a31bb 100644 --- a/config/c-compiler.m4 +++ b/config/c-compiler.m4 @@ -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 |