Horton
Menu

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

Chapman Flack <chap@anastigmatix.net>

View thread
From: Chapman Flack <chap@anastigmatix.net>
To: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, sandeep.thakkar@enterprisedb.com, Thomas Munro <thomas.munro@enterprisedb.com>, David Steele <david@pgmasters.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-08-21T18:03:26Z
Lists: pgsql-hackers 
On 08/21/2018 01:46 PM, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2018-08-21 13:29:20 -0400, Tom Lane wrote:
>>> We've got a buildfarm handy that could answer the question.
>>> Let's just stick a test function in there for a day and see
>>> which animals fail.
> 
>> I think we pretty much know the answer already, anything before 2013
>> will fail.
> 
> Do we know that for sure?  I thought it was theoretical.

I thought I remembered a message where it had been looked up in docs,
but I think the one I was remembering was Peter's "According to my
research (completely untested in practice), you need 2010 for
mixed code and declarations and 2013 for named initialization
of structs." [1] which didn't quite actually say it was documented.

-Chap

[1]
https://www.postgresql.org/message-id/ef986aa7-c7ca-ec34-19d9-fef38716b109%402ndquadrant.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.