Re: More C type errors by default for GCC 14

On Wed, May 10, 2023 at 6:48=E2=80=AFAM Sam James <[email protected]> wrote:
>
>
> Eric Gallager via Gcc <[email protected]> writes:
>
> > On 5/9/23, Jonathan Wakely via Gcc <[email protected]> wrote:
> >> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
> >>> We are currently using gcc 12 and specifying C11.  To experiment with
> >>> these stricter warnings and slowly address them, would we need to bui=
ld
> >>> with a newer C version?
> >>
> >> No, the proposed changes are to give errors (instead of warnings) for
> >> rules introduced in C99. GCC is just two decades late in enforcing the
> >> C99 rules properly!
> >>
> >>
> >>> What practices might the GCC community recommend to a project
> >>> wanting to discover the issues uncovered and slowly address them? I
> >>
> >> -Werror=3Dimplicit-int
> >> -Werror=3Dimplicit-function-declaration
> >> -Werror=3Dint-conversion
> >>
> >
> > Idea for a compromise: What if, instead of flipping the switch on all
> > 3 of these at once, we staggered them so that each one becomes a
> > default in a separate release? i.e., something like:
> >
> > - GCC 14: -Werror=3Dimplicit-function-declaration gets added to the def=
aults
> > - GCC 15: -Werror=3Dimplicit-int gets added to the defaults
> > - GCC 16: -Werror=3Dint-conversion gets added to the defaults
> >
> > That would give people more time to catch up on a particular warning,
> > rather than overwhelming them with a whole bunch all at once. Just an
> > idea.
>
> I think this might be more frustrating than not, althuogh I appreciate
> the intent.
>
> Neal Gompa wasn't keen on the idea at
> https://lore.kernel.org/c-std-porting/CAEg-Je8=3DdQo-jAdu=3DOd5DH+h9AQzGE=
[email protected]/
> because it'd feel like essentially "repeated punches".
>
> Maybe it'd work with some tweaks: I would, however, be more open to GCC 1=
4 having
> implicit-function-declaration,implicit-int (these are so closely related
> that it's not worth dividing the two up) and then say, GCC 15 having int-=
conversion and maybe
> incompatible-pointer-types. But spreading it out too much is likely count=
erproductive.

Right, we've been going through a similar effort with C++ over the
past decade. GCC incrementally becoming more strict on C++ has been an
incredibly painful experience, and it eats away a ton of time that I
would have spent dealing with other problems. Having one big event
where the majority of changes to make the C compiler strict happen
will honestly make it less painful, even if it doesn't seem like it at
the moment.

This is because with as much C++ stuff we have in Linux distributions,
we have so much more C stuff.



--
=E7=9C=9F=E5=AE=9F=E3=81=AF=E3=81=84=E3=81=A4=E3=82=82=E4=B8=80=E3=81=A4=EF=
=BC=81/ Always, there's only one truth!