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
