Tom Lane 96bf88d527 Always use our own versions of *printf(). ... 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		2018-09-26 13:13:57 -04:00
..
ac_func_accept_argtypes.m4
ax_prog_perl_modules.m4
ax_pthread.m4
c-compiler.m4	Always use our own versions of *printf().	2018-09-26 13:13:57 -04:00
c-library.m4	Always use our own versions of *printf().	2018-09-26 13:13:57 -04:00
config.guess	Update config.guess and config.sub	2018-06-11 08:54:58 -04:00
config.sub	Update config.guess and config.sub	2018-06-11 08:54:58 -04:00
docbook.m4
general.m4
install-sh
libtool.m4
llvm.m4	Detect LLVM 7 without specifying binaries explicitly.	2018-09-13 10:42:11 -07:00
Makefile
missing
perl.m4
pkg.m4
prep_buildtree
programs.m4
python.m4
tcl.m4	Make some fixes to allow building Postgres on macOS 10.14 ("Mojave").	2018-09-25 13:23:29 -04:00