Re: More C type errors by default for GCC 14

On Tue, May 9, 2023 at 9:45=E2=80=AFAM Florian Weimer via Gcc <[email protected].=
org> wrote:
>
> The part David quoted above is about this:
>
> $ gcc -fno-gnu89-inline -std=3Dgnu89 t.c
> cc1: error: =E2=80=98-fno-gnu89-inline=E2=80=99 is only supported in GNU9=
9 or C99 mode
>
> And some packages need -fno-gnu89-inline, but also rely on implicit ints
> and implicit function declarations heavily.  With a purely C89-based
> opt-out and the -fno-gnu89-inline limitation, we wouldn't have a way to
> compile these self-contradictory programs.  Hence the idea of
> -fpermissive, in addition to the -std=3Dgnu89 escape hatch.
>
> But perhaps the -fno-gnu89-inline limitation is easy to eliminate.  The
> remaining reason for -fpermissive would be a flag that is accepted by
> both gcc and g++, in case a package build system passes CFLAGS to g++ as
> well, which sometimes happens.  And -fno-gnu89-inline is currently not
> accepted by g++.  But in the Fedora package set, this (some C++ and a
> C89 requirement) must be exceedingly rare because it's a subset of the
> already tiny set of -fno-gnu89-inline -std=3Dgnu89 packages.

I think I wrote that error, back in 2007, because I thought it was odd
to rely on the C99 semantics for inline functions when not using C99.
And to encourage people to move to C99.  But I wouldn't be surprised
if the compiler just works without the error.  It would just require
adding a few test cases similar to gcc.dg/inline-18.c through
inline-21.c (well, inline-21.c would have to be removed or rewritten).

Ian