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
