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

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: 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>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Thomas Munro <thomas.munro@enterprisedb.com>, David Steele <david@pgmasters.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-08-22T12:02:11Z
Lists: pgsql-hackers
Hi,

On 2018-08-22 17:17:27 +0530, Sandeep Thakkar wrote:
> > We build windows binaries (>=9.3) on Windows 7 and Windows Server 2012 R2.
> For 9.3, the Visual Studio version is 2010 and for 9.4 and v10, we use
> 2013. For v11, we use 2017.

Sndeep: Thanks for the information.  Did you ever encounter problems (at
build or during runtime) with using those binaries on older platforms?

Everyone: Given the fact that all the people building windows packages
currently use a new enough stack by a fair margin, I think we should
conclude that there's no obstacle on the windows side of things.


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)

Questions:

- do we want to make declarations at arbitrary points errors? It's
  already a warning currently.
- other new restrictions that we want to introduce at the same time?

Greetings,

Andres Freund


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.