More C type errors by default for GCC 14

Jonathan Wakely
Tue May 9 15:14:28 GMT 2023

On Tue, 9 May 2023 at 16:04, David Edelsohn via Gcc <> wrote:
> Yes, GCC has two, distinct user groups / use cases, but GCC also has a very
> unique and crucial role, as the foundation for a large portion of the
> GNU/Linux and FOSS software ecosystem.  This proposal is missing a
> motivation for this change, especially making new errors the default.
> GCC needs to be proactive, not reactive, without annoying and frustrating
> its user base.  Clang has been making some aggressive changes in warnings,
> but its constituency expects that.  Developers who want that experience
> already will use Clang, so why annoy developers who prefer the GCC
> experience and behavior?  The new warnings and errors help some developers
> and improve software security, but also drive some developers away, or at
> least cause them to reass their choice of toolchain.
> Maybe we need additional front-end aliases "gcclang" and "gcclang++" for
> GCC to provide an experience more like Clang for those who desire that.
> GCC isn't Clang and I fear that GCC is going down a path that annoys and
> frustrates both user groups -- it's not sufficiently aggressive for those
> who prefer Clang and it's too aggressive for those who wish backward
> compatibility.

This isn't "be like Clang", this is "diagnose things that have been
invalid C since 1999".

Accepting invalid code by default is a disservice to users. Those who
need to compile invalid C code can use an extra option to allow it,
the default should be to tell users their code is doing something bad.

More information about the Gcc mailing list