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

Always use our own versions of *printf().

Browse Source 
We've spent an awful lot of effort over the years in coping with
platform-specific vagaries of the *printf family of functions.  Let's just
forget all that mess and standardize on always using src/port/snprintf.c.
This gets rid of a lot of configure logic, and it will allow a saner
approach to dealing with %m (though actually changing that is left for
a follow-on patch).

Preliminary performance testing suggests that as it stands, snprintf.c is
faster than the native printf functions for some tasks on some platforms,
and slower for other cases.  A pending patch will improve that, though
cases with floating-point conversions will doubtless remain slower unless
we want to put a *lot* of effort into that.  Still, we've not observed
that *printf is really a performance bottleneck for most workloads, so
I doubt this matters much.

Patch by me, reviewed by Michael Paquier

Discussion: https://postgr.es/m/2975.1526862605@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2018-09-26 13:13:57 -04:00
parent 758ce9b779
commit 96bf88d527
16 changed files with 19 additions and 509 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
config/c-compiler.m4
View File

@ -20,15 +20,8 @@ fi])# PGAC_C_SIGNED
# PGAC_C_PRINTF_ARCHETYPE
# -----------------------
# 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.)
# We prefer "gnu_printf", as that most closely matches the features supported
# by src/port/snprintf.c (particularly the %m conversion spec).
AC_DEFUN([PGAC_PRINTF_ARCHETYPE],
[AC_CACHE_CHECK([for printf format archetype], pgac_cv_printf_archetype,
[ac_save_c_werror_flag=$ac_c_werror_flag