Horton
Menu

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

David Steele <david@pgmasters.net>

View thread
From: David Steele <david@pgmasters.net>
To: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Stephen Frost <sfrost@snowman.net>
Date: 2018-08-15T18:03:16Z
Lists: pgsql-hackers 
On 8/15/18 12:17 PM, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> 
>> 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.

We already have -Wdeclaration-after-statement to prevent mixed
declarations.  Not sure what to do about comments except manual enforcement.

>> 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.

We use C99 for the pgBackRest project and we've found designated
initializers, compound declarations, and especially variadic macros to
be very helpful.  Only the latter really provides new functionality but
simplifying and clarifying code is always a bonus.

So, +1 from me!

Regards,
-- 
-David
david@pgmasters.net

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.