From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Sandeep Thakkar <sandeep(dot)thakkar(at)enterprisedb(dot)com> |
Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, David Steele <david(at)pgmasters(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Craig Ringer <craig(at)2ndquadrant(dot)com> |
Subject: | Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c) |
Date: | 2018-08-23 00:09:05 |
Message-ID: | 20180823000905.fjthfohmczss4fiw@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-www |
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
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Require-C99-and-thus-MSCV-2013-upwards.patch | text/x-diff | 8.0 KB |
v1-0002-Remove-test-for-VA_ARGS-implied-by-C99.patch | text/x-diff | 26.1 KB |
v1-0003-Introduce-minimal-C99-usage-to-verify-compiler-su.patch | text/x-diff | 5.0 KB |
v1-0004-robot-Add-CI-control-files.patch | text/x-diff | 5.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-08-23 00:16:24 | Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c) |
Previous Message | Tom Lane | 2018-08-23 00:08:47 | Re: SPI_cursor_fetch Memory overrun |
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Atkins | 2018-08-23 00:12:31 | Re: postgresql-archive.org |
Previous Message | Alvaro Herrera | 2018-08-22 23:28:14 | Re: postgresql-archive.org |