Horton
Menu

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

Andres Freund <andres@anarazel.de>

View thread
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>, Craig Ringer <craig@2ndquadrant.com>
Date: 2018-08-23T00:09:05Z
Lists: pgsql-hackers

Attachments

Hi,

On 2018-08-22 05:02:11 -0700, 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)
>
> 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?

Attached is a version doing so. Turns out ripping < msvc 2010 support
allows us to get rid of a fair bit of code.  Using appveyor I tested
that I didn't bungle things too badly.  But I don't really know what I'm
doing in that area, Andrew or Craig, your input would be appreciated.

I tried to update sources.sgml to reflect my understanding of the subset
of C99 we're going to use.  I'd rather start more restrictive and then
argue about relaxing things separately.


There's a few further potential cleanups due to relying on c99:
- Use __func__ unconditionally, rather than having configure test for it
- Use inline unconditionally, rather than having configure test for it
- Remove tests for AC_TYPE_INTPTR_T, AC_TYPE_UINTPTR_T,
  AC_TYPE_LONG_LONG_INT, we can rely on them being present.
- probably more in that vein


I'd rather do these separately lateron, in case one of them causes
trouble on some animals.


There's some potential ones I think we should *not* do:
- remove AC_C_FLEXIBLE_ARRAY_MEMBER, and rely on it unconditionally.
  I'm disinclined to do this, because C++ IIRC doesn't support it in any
  version, and I don't want to make Peter's life unnecessarily hard.
- remove AC_C_RESTRICT check, rely on it unconditionally: MSVC still
  spells this differently.


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.