Re: Removing obsolete configure checks

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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