Horton
Menu

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, "Joshua D. Drake" <jd@commandprompt.com>, 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:16:24Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> 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 wouldn't be in too much of a hurry to do that, particularly not the
third item.  You are confusing "compiler is c99" with "system headers
are c99".  Moreover, I don't see that we're buying much with such
changes.

			regards, tom lane

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.