RFR: 8224087: Compile C code for at least C99 Standard compliance

[Thomas Stüfe]

Hi David,

Thank you for doing this, this looks all very good.

I wish though we had a clear whitelist of features to use or blacklist for
features to avoid. Most developers do not use Windows as a primary
platform, so it will always be a surprise whether Windows breaks in submit
tests.

I am also (a bit) concerned about C99 features creeping in which would
prevent verbatim backporting of patches to older releases. But let’s see if
that is really a problem in practice.

Thanks, Thomas


On Tue 21. May 2019 at 02:58, David Holmes <david.holmes at oracle.com> wrote:

> Thank you everyone for taking a look at this.
>
> Here is version 2:
>
> http://cr.openjdk.java.net/~dholmes/8224087/webrev.v2/
>
> Changes:
> - set c99 rather than gnu99
> - Volker's change for xlc to match gcc and clang
> - added short note to build doc (can do wiki later)
> - cosmetic change of name to make variable based on other feedback
> during the C++14 discussion
>
> Thanks,
> David
>
> On 20/05/2019 5:40 pm, David Holmes wrote:
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8224087
> > webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/
> >
> > The need to remove a for-loop declaration expression to appease gcc 4.8
> > annoyed me enough to investigate setting C99 as our minimum allow
> > C-language level when compiling. It turned out to be a lot more complex
> > a situation than I thought due to toolchain quirks. See lots of details
> > in the bug report.
> >
> > To summarise the changes:
> > - gcc: force to -std=gnu99
> > - clang force to -std=gnu99
> > - Solaris studio - no effective change
> > - Visual Studio - no change
> > - xlc - no effective change (but we use the explicit flag rather than
> > accepting it as default)
> >
> > I've checked how this works with all the toolchains except xlc as I have
> > no access to that. Some assistance from someone who can verify the
> > correctness on xlc would be appreciated.
> >
> > Thanks,
> > David
>