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

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.

I just launched gaur/pademelon builds for you, though I'm quite certain
they'll both report "unsupported". 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. 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).

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.

regards, tom lane