Обсуждение: Removing obsolete configure checks

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

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

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2020-02-20 19:00, Tom Lane wrote:
>> 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).

Yeah, I misread it the first time.

> cbrt is probably a mistake or outdated.

Right; at least, Microsoft's documentation claims to have it.  We'll
soon find out.

> 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 forgot that your pending patch would nuke those, or I wouldn't
have listed them.

>> 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.

Hmm.  If I thought they'd actually put out a new release sometime soon,
I'd be content to wait for that.  Seems like they have forgotten the
rule about "great artists ship", though.  Maybe we need to just
periodically grab their git master?  Keeping all committers in sync
would be a problem though.

            regards, tom lane

On Fri, Feb 21, 2020 at 7:00 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

I think the same now applies to <wctype.h>, without gaur.  So I
propose the attached.  I split it into two patches, because 0001 is
based on scraping build farm configure output, while 0002 is an
educated guess and might finish up needing to be reverted if I'm
wrong.

Thomas Munro <thomas.munro@gmail.com> writes:
> On Fri, Feb 21, 2020 at 7:00 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> I think the same now applies to <wctype.h>, without gaur.  So I
> propose the attached.  I split it into two patches, because 0001 is
> based on scraping build farm configure output, while 0002 is an
> educated guess and might finish up needing to be reverted if I'm
> wrong.

+1.  SUSv2 is perfectly clear that <wctype.h> is supposed to declare
these functions.  I'm not surprised that gaur's 1996-ish system headers
failed to see into the future; but prairiedog is up to speed on this
point, and I should think all the surviving BF animals are too.

            regards, tom lane

On Sat, Jul 23, 2022 at 4:05 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > On Fri, Feb 21, 2020 at 7:00 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> 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.
>
> > I think the same now applies to <wctype.h>, without gaur.  So I
> > propose the attached.  I split it into two patches, because 0001 is
> > based on scraping build farm configure output, while 0002 is an
> > educated guess and might finish up needing to be reverted if I'm
> > wrong.
>
> +1.  SUSv2 is perfectly clear that <wctype.h> is supposed to declare
> these functions.  I'm not surprised that gaur's 1996-ish system headers
> failed to see into the future; but prairiedog is up to speed on this
> point, and I should think all the surviving BF animals are too.

Thanks.  After looking more closely I pushed it as one commit.  (I
suspect that we have some redundant #includes around here but my
current mission is focused on redundant configure/portability gloop.)