From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by sourceware.org (Postfix) with ESMTPS id 6D1C03858C66 for ; Wed, 10 May 2023 10:57:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6D1C03858C66 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gompa.dev Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-96622bca286so880578066b.1 for ; Wed, 10 May 2023 03:57:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683716231; x=1686308231; h=content-transfer-encoding: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=YlfR1FzDe1uYav4nCTjIKRl3Rc5yU+Jm6Necwy2JcQ0=; b=jINl3/E9TVqY9sJhDy6fcxkXzYzmx8gpthXfvlQEf9ZH9WfG8tOGwKBs8NEqnQGZni Hbok9PpP6S88+n4ujS7Q3NF5rkZtF3Qhzup7gfLdmK2Yl1kbZhsMApvWRrM2c0d0sPav V4MsRNQu9BWsWgR6+lHAZv+ESToON9x96zgPCxthnhYQus/j7wlu1qLlEM/2hPG/zqur RDqJqJ035xRnp9Y4aT3SMVTWMh/kBjajBapymhJINqjWTcquSx3esGJh/m8TWI9P0caF FautRlnQwxBJ14DIy1+efvZtcWCEX0GtugRvLDLp1eSVo1l7NbMr8u+49HHac5aly56P OUig== X-Gm-Message-State: AC+VfDy8FPNTMvgplmDqG1VoJBrEC4oXCSoB9sWVEY6si2Axqa5+s+s7 N1jEkOvoo+nTp5/Z8+Tx+uP6g0pM9RXyHdtG X-Google-Smtp-Source: ACHHUZ4Paug0mh8ClP6KfPEztSLpNGmF9xnZMFsAjtqOCDgovsISZGQUl2BKoMpQwAurTK6YQtUM1Q== X-Received: by 2002:a17:907:948c:b0:94f:3312:3daf with SMTP id dm12-20020a170907948c00b0094f33123dafmr15567301ejc.66.1683716230555; Wed, 10 May 2023 03:57:10 -0700 (PDT) Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com. [209.85.208.48]) by smtp.gmail.com with ESMTPSA id gv28-20020a1709072bdc00b00965cfc209d5sm2548869ejc.8.2023.05.10.03.57.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 May 2023 03:57:10 -0700 (PDT) Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-50bc25f0c7dso12999848a12.3 for ; Wed, 10 May 2023 03:57:09 -0700 (PDT) X-Received: by 2002:a17:907:805:b0:94f:704d:a486 with SMTP id wv5-20020a170907080500b0094f704da486mr14235833ejb.32.1683716229263; Wed, 10 May 2023 03:57:09 -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> <87mt2cihs6.fsf@gentoo.org> In-Reply-To: <87mt2cihs6.fsf@gentoo.org> From: Neal Gompa Date: Wed, 10 May 2023 06:56:32 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: More C type errors by default for GCC 14 To: Sam James Cc: Eric Gallager , Jonathan Wakely , joel@rtems.org, David Edelsohn , Eli Zaretskii , Jakub Jelinek , =?UTF-8?Q?Arsen_Arsenovi=C4=87?= , gcc@gcc.gnu.org, c-std-porting@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,BODY_8BITS,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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: On Wed, May 10, 2023 at 6:48=E2=80=AFAM Sam James wrote: > > > Eric Gallager via Gcc writes: > > > On 5/9/23, Jonathan Wakely via Gcc wrote: > >> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote: > >>> We are currently using gcc 12 and specifying C11. To experiment with > >>> these stricter warnings and slowly address them, would we need to bui= ld > >>> with a newer C version? > >> > >> No, the proposed changes are to give errors (instead of warnings) for > >> rules introduced in C99. GCC is just two decades late in enforcing the > >> C99 rules properly! > >> > >> > >>> What practices might the GCC community recommend to a project > >>> wanting to discover the issues uncovered and slowly address them? I > >> > >> -Werror=3Dimplicit-int > >> -Werror=3Dimplicit-function-declaration > >> -Werror=3Dint-conversion > >> > > > > Idea for a compromise: What if, instead of flipping the switch on all > > 3 of these at once, we staggered them so that each one becomes a > > default in a separate release? i.e., something like: > > > > - GCC 14: -Werror=3Dimplicit-function-declaration gets added to the def= aults > > - GCC 15: -Werror=3Dimplicit-int gets added to the defaults > > - GCC 16: -Werror=3Dint-conversion gets added to the defaults > > > > That would give people more time to catch up on a particular warning, > > rather than overwhelming them with a whole bunch all at once. Just an > > idea. > > I think this might be more frustrating than not, althuogh I appreciate > the intent. > > Neal Gompa wasn't keen on the idea at > https://lore.kernel.org/c-std-porting/CAEg-Je8=3DdQo-jAdu=3DOd5DH+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 1= 4 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 count= erproductive. 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. This is because with as much C++ stuff we have in Linux distributions, we have so much more C stuff. -- =E7=9C=9F=E5=AE=9F=E3=81=AF=E3=81=84=E3=81=A4=E3=82=82=E4=B8=80=E3=81=A4=EF= =BC=81/ Always, there's only one truth!