Horton
Menu

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

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

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: David Steele <david@pgmasters.net>, pgsql-hackers@lists.postgresql.org
Date: 2018-08-15T22:13:59Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> On 2018-08-15 15:57:43 -0400, Tom Lane wrote:
>> I'd always thought this was only in C++.  This alone might be a sufficient
>> reason to drop C89 compiler support ...

> It's also IIRC reasonably widely supported from before C99. So, for the
> sake of designated initializers, for loop scoping, snprintf, let's do
> this in master?

Nitpick: snprintf is an independent concern: that's from the C library,
not from the compiler.  To drive the point home, I could still test
master on "gaur" if I were to install a just-slightly-newer gcc on that
machine (its existing gcc installation isn't native either...); but
replacing its libc is a nonstarter.

Experimenting here says that even reasonably modern gcc's won't take
declarations-inside-for without "--std=c99" or such.  No idea about
other compilers.  So we'd have a little bit of work to do on
configuration before we could open the floodgates on this.

			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.