Over in the thread at [1] we agreed to remove assorted code that copes
with missing <stdint.h>, on the grounds that C99 requires that header
so we should not have to cater anymore for platforms without it.
This logic could obviously be carried further. I scraped the buildfarm
configure logs to see what other tests seem pointless (on the grounds that
every active animal reports the same result) and found a fair number.
I think we can just remove these tests, and the corresponding
src/port/ files where there is one:
fseeko
isinf
memmove
rint
signed types
utime
utime.h
wchar.h
All of the above are required by C99 and/or SUSv2, and the configure-using
buildfarm members are unanimous in reporting that they have them, and
msvc/Solution.pm expects Windows to have them. Removing src/port/isinf.c
will let us get rid of a few more configure tests too:
# Look for a way to implement a substitute for isinf()
AC_CHECK_FUNCS([fpclass fp_class fp_class_d class], [break])
although that code path is never taken so it won't save much.
I believe that we can also get rid of these tests:
flexible array members
cbrt
intptr_t
uintptr_t
as these features are likewise required by C99. Solution.pm thinks that
MSVC does not have the above, but I suspect its information is out of
date. We could soon find out from the buildfarm, of course.
I also noted that these header checks are passing everywhere,
which is unsurprising because they're required by C99 and/or POSIX:
ANSI C header files
inttypes.h
memory.h
stdlib.h
string.h
strings.h
sys/stat.h
sys/types.h
unistd.h
Unfortunately we're not actually asking for any of those to be probed
for --- it looks like Autoconf just up and does that of its own accord.
So we can't get rid of the tests and save configure cycles thereby.
But we can skip testing the HAVE_FOO_H symbols for them. We mostly
were already, but there's one or two exceptions.
There are a few other tests that are getting the same results in
all buildfarm configure checks, but Solution.pm is injecting different
results for Windows, such as what to expand "inline" to. Conceivably
we could hard-code that based on the WIN32 #define and remove the
configure probes, but I'm inclined to think it's not worth the
trouble and possible loss of flexibility.
Barring objections I'll go make this happen.
regards, tom lane
[1]
https://www.postgresql.org/message-id/flat/5d398bbb-262a-5fed-d839-d0e5cff3c0d7%402ndquadrant.com
