More C type errors by default for GCC 14
Tue May 9 15:14:28 GMT 2023
On Tue, 9 May 2023 at 16:04, David Edelsohn via Gcc <email@example.com> 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
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