Re: C99 compliance for src/port/snprintf.c

On 08/16/2018 12:05 PM, Andres Freund wrote:
> Hi,
>
> On 2018-08-16 11:41:30 -0400, Tom Lane wrote:
>> Andres Freund <andres(at)anarazel(dot)de> writes:
>>> But enabling C99 support triggered a somewhat weird failure on
>>> protosciurus (also solaris, but gcc)
>>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=protosciurus&dt=2018-08-16%2013%3A37%3A46
>>> It detects C99 support successfully via -std=gnu99 but then fails
>>> somewhere during build with:
>>> ../../../../src/include/utils/float.h:71: error: `__builtin_infinity' undeclared (first use in this function)
>>> While I'd personally have no problem kicking gcc 3.4 to the curb, I'm
>>> still confused what causes this error mode. Kinda looks like
>>> out-of-sync headers with gcc or something.
>> Yeah, this is *absolutely* unsurprising for a non-native gcc installation
>> on an old platform. It only works to the extent that the platform's
>> library headers are up to snuff. The gcc installation process actually
>> knows enough to do a certain amount of editing of the platform's headers,
>> and install "fixed" copies of those headers where gcc will find them
>> before the ones in /usr/include. But it looks like the fixing didn't
>> account for __builtin_infinity on this platform. Maybe a newer gcc
>> would get it right.
> Sure, but that still requires the headers to behave differently between
> C89 and C99 mode, as this worked before. But it turns out there's two
> different math.h implementation headers, depending on c99 being enabled
> (math_c99.h being the troublesome). If I understand correctly the
> problem is more that the system library headers are *newer* (and assume
> a sun studio emulating/copying quite a bit of gcc) than the gcc that's
> being used, and therefore gcc fails.
>
> Gcc 3.4.3 has been released November 4, 2004, whereas solaris 10 is from
> January 31, 2005. The sun studio used for castoroides running on, I
> assume, the same hardware, is quite a bit newer in turn.
>
>
>> I just launched gaur/pademelon builds for you, though I'm quite certain
>> they'll both report "unsupported".
> Yea, that seems fairly likely.
>
>
>> If we go through with this, my plan would be to retire pademelon
>> (vendor's compiler) and see if I can install gcc 4.something to
>> replace the 2.95.3 version that gaur is using.
> K.
>
>
>> The -ansi option that dromedary is using is certainly losable, too
>> (I'd probably replace it with either --std=c99 or --std=gnu99,
>> whichever autoconf *doesn't* pick by default, just to be contrary).
> Makes sense.
>
>
>> Andrew is going to need to give us a policy decision on whether to
>> keep using the existing animal names or take out new ones for these
>> rather-significantly-modified configurations.
> CCed.
>

The usual policy is that animal names need to change if the OS or
compiler names change, but not if just the versions of those change.
There is a script in the suite to update those settings, and the admins
can also help if necessary.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services