More C type errors by default for GCC 14

Eli Zaretskii eliz@gnu.org
Wed May 10 12:06:37 GMT 2023


> From: Neal Gompa <neal@gompa.dev>
> Date: Wed, 10 May 2023 06:56:32 -0400
> Cc: Eric Gallager <egall@gwmail.gwu.edu>, Jonathan Wakely <jwakely.gcc@gmail.com>, joel@rtems.org, 
> 	David Edelsohn <dje.gcc@gmail.com>, Eli Zaretskii <eliz@gnu.org>, Jakub Jelinek <jakub@redhat.com>, 
> 	Arsen Arsenović <arsen@aarsen.me>, gcc@gcc.gnu.org, 
> 	c-std-porting@lists.linux.dev
> 
> On Wed, May 10, 2023 at 6:48 AM Sam James <sam@gentoo.org> wrote:
> >
> > Neal Gompa wasn't keen on the idea at
> > https://lore.kernel.org/c-std-porting/CAEg-Je8=dQo-jAdu=Od5DH+h9AQzGE_4ghzgx_ow4RyJVPwFTg@mail.gmail.com/
> > because it'd feel like essentially "repeated punches".
> >
> > Maybe it'd work with some tweaks: I would, however, be more open to GCC 14 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 counterproductive.
> 
> 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.

But not having such an event, ever, would be even less painful.


More information about the Gcc mailing list