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

Hi,

On 2018-08-16 11:41:30 -0400, Tom Lane wrote:
> Andres Freund  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.

Greetings,

Andres Freund