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: Alvaro Herrera <alvherre@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-08-15T22:18:21Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> On 2018-08-15 14:05:29 -0400, Tom Lane wrote:
>> Still want to argue for no backpatch?

> I'm a bit confused. Why did you just backpatch this ~two hours after
> people objected to the idea?  Even if it were during my current work
> hours, I don't even read mail that often if I'm hacking on something
> complicated.

If a consensus emerges to deal with this some other way, reverting
isn't hard.  But I think it's pretty clear at this point that we're
dealing with real bugs versus entirely hypothetical bugs, and that's
not a decision that's hard to make IMO.

			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.