On 2020-02-20 19:00, Tom Lane wrote:
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
makes sense
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.
The flexible array members test on Solution.pm looks correct to me
(define to empty if supported, else define to 1). cbrt is probably a
mistake or outdated. The intptr_t/uintptr_t results are inconsistent:
It correctly defines intptr_t to empty, so that it will use the existing
typedef, but it does not define HAVE_INTPTR_T, but nothing uses that
anyway. But these are gone now anyway.
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.
Autoconf git master seems to have modernized that a little bit. For
instance, HAVE_STDLIB_H and HAVE_STRING_H are always defined to 1, just
for backward compatibility. If we wanted to fiddle with this, I'd
consider importing the updated macro. Not sure if it's worth it though.
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.
MSVC indeed does not appear to support plain inline.
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.
Right, better to leave it.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
