More C type errors by default for GCC 14

Jonathan Wakely jwakely.gcc@gmail.com
Tue May 9 20:40:31 GMT 2023


On Tue, 9 May 2023, 21:13 David Edelsohn, <dje.gcc@gmail.com> wrote:

> On Tue, May 9, 2023 at 3:22 PM Eli Zaretskii via Gcc <gcc@gcc.gnu.org>
> wrote:
>
>> > Date: Tue, 9 May 2023 21:07:07 +0200
>> > From: Jakub Jelinek <jakub@redhat.com>
>> > Cc: Jonathan Wakely <jwakely.gcc@gmail.com>, arsen@aarsen.me,
>> gcc@gcc.gnu.org
>> >
>> > On Tue, May 09, 2023 at 10:04:06PM +0300, Eli Zaretskii via Gcc wrote:
>> > > > From: Jonathan Wakely <jwakely.gcc@gmail.com>
>> > > > Date: Tue, 9 May 2023 18:15:59 +0100
>> > > > Cc: Arsen Arsenović <arsen@aarsen.me>, gcc@gcc.gnu.org
>> > > >
>> > > > On Tue, 9 May 2023 at 17:56, Eli Zaretskii wrote:
>> > > > >
>> > > > > No one has yet explained why a warning about this is not enough,
>> and
>> > > > > why it must be made an error.  Florian's initial post doesn't
>> explain
>> > > > > that, and none of the followups did, although questions about
>> whether
>> > > > > a warning is not already sufficient were asked.
>> > > > >
>> > > > > That's a simple question, and unless answered with valid
>> arguments,
>> > > > > the proposal cannot make sense to me, at least.
>> > > >
>> > > > People ignore warnings. That's why the problems have gone unfixed
>> for
>> > > > so many years, and will continue to go unfixed if invalid code keeps
>> > > > compiling.
>> > >
>> > > People who ignore warnings will use options that disable these new
>> > > errors, exactly as they disable warnings.  So we will end up not
>> >
>> > Some subset of them will surely do that.  But I think most people will
>> just
>> > fix the code when they see hard errors, rather than trying to work
>> around
>> > them.
>>
>> The same logic should work for warnings.  That's why we have warnings,
>> no?
>>
>
> This seems to be the core tension.  If developers cared about these
> issues, they would enable appropriate warnings and -Werror.
>
> The code using these idioms is not safe and does create security
> vulnerabilities.  And software security is increasingly important.
>
> The concern is using the good will of the GNU Toolchain brand as the tip
> of the spear or battering ram to motivate software packages to fix their
> problems. It's using GCC as leverage in a manner that is difficult for
> package maintainers to avoid.  Maybe that's a necessary approach, but we
> should be clear about the reasoning.  Again, I'm not objecting, but let's
> clarify why we are choosing this approach.
>

So let's do it. Let's write a statement saying that the GCC developers
consider software security to be of increasing importance, and that we
consider it irresponsible to default to accepting invalid constructs in the
name of backwards compatibility. State that we will make some changes which
were a break from GCC's traditional stance, for the good of the ecosystem.

Given recent pushes to discourage or outright ban the use of memory-safe
languages in some domains, I think it would be good to make a strong
statement about taking the topic seriously. And not just make a statement,
but take action too.

If we don't do this, I believe it will harm GCC in the long run. The vocal
minority who want to preserve the C they're used to, like some kind of
historical reenactment society, would get their wish: it would become a
historical dead end and go nowhere.


More information about the Gcc mailing list