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: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-08-15T16:17:18Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Aug 15, 2018 at 11:52 AM, Andres Freund <andres@anarazel.de> wrote:
>> We could just mandate C99, more generally.
>> 
>> /me goes and hides in a bush.

> It's hard to believe that would cost much.

I think we have done that, piece by piece, where it was actually buying us
something.  In particular we've gradually moved the goalposts for *printf
compliance, and I'm proposing here to move them a bit further.  I'm not
sure what "we're going to insist on C99" even means concretely, given
this position ...

> Personally, I'd prefer to
> continue avoiding // comments and intermingled declarations of
> variables and code on grounds of style and readability.

... which I agree with.

> But it's kind
> of difficult to believe that we really need to worry about people
> still running 20-year old compilers very much.

Sure.  It's been a long time since anybody worried about those as
optimization targets, for instance.  Still, I'm not in favor of
actively breaking compatibility unless it buys us something.

			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.