From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id 5A9923858C33 for ; Tue, 9 May 2023 20:13:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5A9923858C33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-50bc1612940so11867166a12.2 for ; Tue, 09 May 2023 13:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683663223; x=1686255223; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=imO9p77yZwlL8/WK0CSQJMhMayIjtJmem/L5BohltTg=; b=b3rcK2kECG6+FiRbsgdbnD3pTCIwBQWcIWQddjhjRtDCkd7PQAlhLAECKb9ckqki4s g/kJVtPRFcv/iPcWM7zrjBr5tl3J5jYP5R5B7zGTtiMbA09vO1R47sGaJO+o/Q+3T+yk XA4PtkBC6AtqyPt1Q2IRGByiFGYZxRbpcgv3iD8K2zJBentz3CC0GsrfBQG06FSMJmzj oGQBwfRgQhAid1zCKDAC2xdDX1pU+9/7h6PgqOVtB7HhKJOKsmZo7CcNsVRT+6UBUW5a mXd60MMGkprrVrKJ/w7Ji9ZFWX3g5wSI/PYoQjMfq65S8hhbUgEdZl/4+6+YOSMjwpmS VrUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683663223; x=1686255223; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=imO9p77yZwlL8/WK0CSQJMhMayIjtJmem/L5BohltTg=; b=ZuHcR6PzzcRJJe3vowf1JxTkjYOBEqu1KjqqwGeUk/GXP24cP/HLZj/Yz/NSNM6gsb SqHnDPD+sRoAC+UQDNB2hYKFqCV6ap+U3kGUPEyeka2ET+VoFrh5cq0IaMNxdK5+SEi6 UMAO4VsgL+A15Ujz9Hyr3ke7/W7H/MnP343pis0hZqqyfH/T7eLO4wxf5P4BSbpHHcAP oPgNcrxQJp1ZFACzak1kgEnEDRYHW8qKlmVCjmY7HHYgQN+zXpTcsAh9Cbi0e+S4HU3C iknqBkGXYXUxlQraVF2Z8YmVmZ5pHzhmBrV9enbL6IFcHiphefUq+C+tw0D5F4FBWOup NeLQ== X-Gm-Message-State: AC+VfDxSQuexjcV52JsfBa4pvzSVGVuTi/rALmmjMjwQuLlXB82tdk1Q KdGAkRmzVZ8Dya/1dQM6zhK5eXKkCQMoIfvKIes= X-Google-Smtp-Source: ACHHUZ4jQqjglXNxqDxt7kGPtUenX3FeMxhp41RMoHqouPJfSxzRQ5Zhw8vAS4svUqN0Rsnq2kkLzKzhXDlWJL+UBB4= X-Received: by 2002:aa7:df03:0:b0:50b:fd52:2f42 with SMTP id c3-20020aa7df03000000b0050bfd522f42mr12333455edy.4.1683663222885; Tue, 09 May 2023 13:13:42 -0700 (PDT) MIME-Version: 1.0 References: <877cth66qb.fsf@oldenburg.str.redhat.com> <20230509102201.6aa2a7d14fdb2f1e7abff449@killthe.net> <87r0rp5uf8.fsf@aarsen.me> <83ttwla1ep.fsf@gnu.org> <83lehx9vix.fsf@gnu.org> <83fs859unu.fsf@gnu.org> In-Reply-To: <83fs859unu.fsf@gnu.org> From: David Edelsohn Date: Tue, 9 May 2023 16:13:30 -0400 Message-ID: Subject: Re: More C type errors by default for GCC 14 To: Eli Zaretskii , Jakub Jelinek , jwakely.gcc@gmail.com Cc: arsen@aarsen.me, gcc@gcc.gnu.org Content-Type: multipart/alternative; boundary="000000000000525cd305fb4864ba" X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000525cd305fb4864ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 9, 2023 at 3:22=E2=80=AFPM Eli Zaretskii via Gcc wrote: > > Date: Tue, 9 May 2023 21:07:07 +0200 > > From: Jakub Jelinek > > Cc: Jonathan Wakely , 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 > > > > Date: Tue, 9 May 2023 18:15:59 +0100 > > > > Cc: Arsen Arsenovi=C4=87 , 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 argument= s, > > > > > the proposal cannot make sense to me, at least. > > > > > > > > People ignore warnings. That's why the problems have gone unfixed f= or > > > > 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 arou= nd > > 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. Thanks, David --000000000000525cd305fb4864ba--