Horton
Menu

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

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-08-15T15:52:37Z
Lists: pgsql-hackers 
Hi,

On 2018-08-15 11:41:46 -0400, Tom Lane wrote:
> BTW, independently of whether to back-patch, it strikes me that what
> we ought to do in HEAD (after applying this) is to just assume we have
> C99-compliant behavior, and rip out the baroque logic in psnprintf
> and appendPQExpBufferVA that tries to deal with pre-C99 snprintf.
> I don't expect that'd save any really meaningful number of cycles,
> but at least it'd buy back the two added instructions mentioned above.
> I suppose we could put in a configure check that verifies whether
> the system snprintf returns the right value for overrun cases, though
> it's hard to believe there are any platforms that pass the 'z' check
> and would fail this one.

We could just mandate C99, more generally.

/me goes and hides in a bush.

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.