Horton
Menu

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

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-08-15T14:58:54Z
Lists: pgsql-hackers 
On Tue, Aug 14, 2018 at 7:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm almost tempted to think that the reasons above make this a
> back-patchable bug fix.  Comments?

No objections to changing the behavior.  Have you checked whether
there are any noticeable performance consequences?

Back-patching seems a bit aggressive to me considering that the danger
is hypothetical.  I'd want to have some tangible evidence that
back-patching was going help somebody. For all we know somebody's got
an extension which they only use on Windows that happens to be relying
on the current behavior, although more likely still (IMHO) is that it
there is little or no code relying on either behavior.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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.