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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Dave Page <dpage@pgadmin.org>, David Steele <david@pgmasters.net>, pgsql-hackers@lists.postgresql.org
Date: 2018-08-16T15:41:30Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.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


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Remove test for VA_ARGS, implied by C99.

  2. Introduce minimal C99 usage to verify compiler support.

  3. Require C99 (and thus MSCV 2013 upwards).

  4. Require a C99-compliant snprintf(), and remove related workarounds.

  5. Try to enable C99 in configure, but do not rely on it (yet).

  6. Make snprintf.c follow the C99 standard for snprintf's result value.

  7. Clean up assorted misuses of snprintf()'s result value.