Horton
Menu

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

Thomas Munro <thomas.munro@enterprisedb.com>

View thread
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, David Steele <david@pgmasters.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-08-15T22:54:01Z
Lists: pgsql-hackers 
On Thu, Aug 16, 2018 at 10:40 AM, Andres Freund <andres@anarazel.de> wrote:
> Hi,
>
> On 2018-08-15 18:31:10 -0400, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
>> > On 2018-08-15 18:13:59 -0400, Tom Lane wrote:
>> >> Experimenting here says that even reasonably modern gcc's won't take
>> >> declarations-inside-for without "--std=c99" or such.
>>
>> > I think autoconf's magic knows about most of that:
>> >  — Macro: AC_PROG_CC_C99
>>
>> Ah, of course.  What about the MSVC build?
>
> It looks like it mostly just enables that by default. But I only looked
> cursorily.  It's a bit annoying because that makes it harder to be sure
> which animals support what.  Looks like e.g. hammerkop (supposedly msvc
> 2005) might not support the subset we want; not that I'd loose sleep
> over raising the minimum msvc in master a bit.

Really?  I am not an MSVC user but I had the impression that their C
mode (/TC or files named .c) was stuck on C89/C90 as a matter of
policy, as Herb Sutter explained here (though maybe the situation has
changed since then):

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/

That's presumably why cfbot's appveyor build always complains about
people declaring variables after statements.  To allow that particular
language feature, it looks like you have to tell it that your .c file
is really a C++ program with /TP.  But that opens a separate can of
worms, doesn't it?

-- 
Thomas Munro
http://www.enterprisedb.com

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.