From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fencepost.gnu.org (fencepost.gnu.org [IPv6:2001:470:142:3::e]) by sourceware.org (Postfix) with ESMTPS id 292AD3858C31 for ; Wed, 10 May 2023 02:37:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 292AD3858C31 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=gmL3QF7KFOsih7MGhdkY+JoQMHvixgbDpSFv5fnkqrc=; b=SvFr+GsL5mnRRjNb8GaG HWPK343edgxCK2gFRo3ZNo4uGrDupK/dPbEOmHQ03AsP+E7eyV0XpMzZMmf8BeQf/+iLhep/KLCX0 L/L22L5cZZy4RD29DPbJiZr88DS46xI0l9NY77ou17Rzhg8DYQE3yxPBqp+RdTCTuUSsjvLZaQfUK xcOQrm0+6rLS/luZFdZJ6sqvzK5fI6ok+HOGGejEmcCoCiF1BLeBCsRC9WF4eDgyElsouhan/cDPy 9eahxQwDLa04QrJrqBHCXT1lpY2wNMD1lYs5fsE9wyM35gZeJ1ByplAs6x0/dHeZ2A1KusC0EA3tJ Vyrj6BWwfZnYbQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pwZiC-0003VF-Fm; Tue, 09 May 2023 22:37:52 -0400 Date: Wed, 10 May 2023 05:38:57 +0300 Message-Id: <83cz38ap1a.fsf@gnu.org> From: Eli Zaretskii To: Arsen =?utf-8?Q?Arsenovi=C4=87?= Cc: dje.gcc@gmail.com, jakub@redhat.com, jwakely.gcc@gmail.com, gcc@gcc.gnu.org In-Reply-To: <864jolw8id.fsf@aarsen.me> (message from Arsen =?utf-8?Q?Arse?= =?utf-8?Q?novi=C4=87?= on Tue, 09 May 2023 22:21:03 +0200) Subject: Re: More C type errors by default for GCC 14 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> <864jolw8id.fsf@aarsen.me> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > From: Arsen Arsenović > Cc: Eli Zaretskii , Jakub Jelinek , > jwakely.gcc@gmail.com, gcc@gcc.gnu.org > Date: Tue, 09 May 2023 22:21:03 +0200 > > > 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. > > Both the GNU Toolchain and the GNU Toolchain users will benefit from a > stricter toolchain. > > People can and have stopped using the GNU Toolchain due to lackluster > and non-strict defaults. This is certainly not positive for the brand, > and I doubt it buys it much good will. It is not GCC's business to force developers of packages to get their act together. It is the business of those package developers themselves. GCC should give those developers effective and convenient means of detecting any unsafe and dubious code and of correcting it as they see fit. Which GCC already does by emitting warnings. GCC should only error out if it is completely unable to produce valid code, which is not the case here, since it has been producing valid code for ages. It is a disservice to GCC users if a program that compiled yesterday and worked perfectly well suddenly cannot be built because GCC was upgraded, perhaps due to completely unrelated reasons. It would be a grave mistake on the part of GCC to decide that part of its mission is to teach package developers how to write their code and when and how to modify it.