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: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-08-15T19:18:57Z
Lists: pgsql-hackers 
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 08/15/2018 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.

> A decade or so ago I would have strongly agreed with you. But the 
> language trend seems to be in the other direction. And there is 
> something to be said for declaration near use without having to use an 
> inner block. I'm not advocating that we change policy, however.

FWIW, the issue I've got with what C99 did is that you can narrow the
*start* of the scope of a local variable easily, but not the *end* of
its scope, which seems to me to be solving at most half of the problem.
To solve the whole problem, you end up needing a nested block anyway.

I do dearly miss the ability to easily limit the scope of a loop's
control variable to just the loop, eg

	for (int i = 0; ...) { ... }

But AFAIK that's C++ not C99.

			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.