Horton
Menu

Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)

David Steele <david@pgmasters.net>

View thread
From: David Steele <david@pgmasters.net>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, "Joshua D. Drake" <jd@commandprompt.com>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-08-22T16:56:01Z
Lists: pgsql-hackers 
On 8/22/18 10:56 AM, Peter Eisentraut wrote:
> On 22/08/2018 14:02, Andres Freund wrote:
>> If we agree on that, I'm going to propose a patch that includes:
>> - relevant cleanups to configure
>> - adapts sources.sgml to refer to C99 instead of C89
>> - add some trivial conversions to for(int i;;) and struct initializers,
>>   so the relevant old animals fail
>> - adds a configure check to enable errors with vla usage (-Werror=vla)
> 
> sounds good

Sounds good to me.

> 
>> - do we want to make declarations at arbitrary points errors? It's
>>   already a warning currently.
> 
> While there are legitimate criticisms, it's a standard feature in C,
> C++, and many other languages, so I don't see what we'd gain by fighting it.

+1.=

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