On Tue, Oct 10, 2023 at 12:09 PM Florian Weimer via Gcc <gcc@gcc.gnu.org>
wrote:

> * Jakub Jelinek:
>
> > On Tue, Oct 10, 2023 at 12:30:52PM -0400, Jason Merrill via Gcc wrote:
> >> On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc <gcc@gcc.gnu.org
> >
> >> wrote:
> >>
> >> > Are these code fragments valid C89 code?
> >> >
> >> >   int i1 = 1;
> >> >   char *p1 = i;
> >> >
> >> >   char c;
> >> >   char *p2 = &c;
> >> >   int i2 = p2;
> >> >
> >> > Or can we generate errors for them even with -std=gnu89?
> >> >
> >> > (It will still be possible to override this with -fpermissive or
> >> > -Wno-int-conversion.)
> >> >
> >>
> >> Given that C89 code is unlikely to be actively maintained, I think we
> >> should be permissive by default in that mode.  People compiling with an
> old
> >> -std flag are presumably doing it to keep old code compiling, and it
> seems
> >> appropriate to respect that.
> >
> > Yeah, complete agreement here.
>
> Okay.  It helps with the test suite conversation because -std=gnu89 -w
> is available today, so I can post such patches separately.
>
> >> I'm also (though less strongly) inclined to be permissive in C99 mode,
> and
> >> only introduce the new strictness by default for C11/C17 modes.
> >
> > Especially when the default is -std=gnu17 that can be an option as well.
> >
> > There might be some code in the wild compiled with -std=gnu99 or
> -std=c99 just
> > because it wanted to use C99 features back 15-20 years ago and hasn't
> been
> > adjusted since then, but it might be better to adjust that if needed and
> keep
> > using those flags only when they are needed because the code isn't
> C11/C17/C2X
> > ready.
>
> Linux currently uses -std=gnu99 deliberately in a few places, I believe.
> It would be a shame if we defaulted to permissive mode over there.  I
> would certainly prefer to restrict permissive mode to the C89/C90
> language levels.  We can have this discussion once I post my patch
> (which depends on Jason's permerror enhancement in several ways).
>

C99 is what POSIX assumes up to the next version which should be nearing
release. It moves the baseline to C11.

Also from a safety critical system viewpoint, C99 (and C++03) was still
widely used. In fact the FACE Technical Standard gave only those language
versions for application conformance purposes. C++11 and C++14 were
very recently added as options in a corrigenda that was released in August.
I know this isn't the primary focus for GCC but embedded isn't rare.

From an RTEMS perspective, the OS is primarily built as C11 but that
was  primarily done for access to the atomics defined there not in C99.

So it isn't that the code "isn't ready" for a new language version, it may
be because there are standards still based on older versions or the safety
review process may not accommodate a newer version.  It also could be
as simple as the RTOS vendor does not recommend using it with their
OS which has been through something like a flight qualification.

--joel


>
> Thanks,
> Florian
>
>