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 9FF513857029 for ; Wed, 10 May 2023 11:51:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9FF513857029 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=QPI5Jw7CRl8jhJlsYFXFK+jA/uknjMNHx83HLy0goP8=; b=gOYaDWpahV1WWwmzVYcQ oxkuY24/nfGmQ5nr1+qUgL2avE/V9HXZBxbcv+QUC5CAeBJ2UnZox6xcGycU/BIpzMPmH6JAoAEz6 Gn0VhRfUGxQ7f0PffBEGpws/wqf95SFYz2nkMSKshPXmDfSoYe1Pb1Dj+j9yQXmVxPmwfeNkq9OqZ wJEe8SyguG8Oinqlq40oth1UL591GT9wx44YASqzhjr5jl+pKCiXZqrlWRH499viaukp6u6PpgshE aOFZmV5cDJRG/yFSSCLcFR0aLrIlMl6NXr9BCGUYqSAvKssh1pa0Pymtd2Ssl4GNhdFa7TkFhAbHr 32lWmqKOLQGWJQ==; 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 1pwiLc-00068c-2H; Wed, 10 May 2023 07:51:08 -0400 Date: Wed, 10 May 2023 14:52:13 +0300 Message-Id: <83y1lw8kuq.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: <86o7mspn3a.fsf@aarsen.me> (message from Arsen =?utf-8?Q?Arse?= =?utf-8?Q?novi=C4=87?= on Wed, 10 May 2023 10:36:23 +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> <83cz38ap1a.fsf@gnu.org> <86o7mspn3a.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: dje.gcc@gmail.com, jakub@redhat.com, jwakely.gcc@gmail.com, gcc@gcc.gnu.org > Date: Wed, 10 May 2023 10:36:23 +0200 > > Eli Zaretskii writes: > > > It is not GCC's business to force developers of packages to get their > > act together. > > Why not? Compilers are diagnostic tools besides just machines that > guess what machine code you mean. Diagnostics does not mean error. A warning is also diagnostics. > > 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. > > There's a difference between dubious and unsafe code and code that is > unambiguously wrong, but was chosen to be accepted many years ago. Is GCC indeed capable of reliably distinguishing between these two? And that code is not unambiguously wrong, since it is valid under old standards, and thus can be compiled, and did compile, into a working program. > > 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. > > Producing call code with wrong prototypes is not within my definition of > producing valid code. I don't think I follow. If the produced machine code is valid and does what the programmer meant, why should we care about the prototypes? > > 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. > > Please see the various porting-to pages. Compilers stop being able to > produce code with older versions of programs because of them being a > lil' too lax and the programs accidentally relying on that every year. > There's nothing wrong there. > > If compilers stopped being lax, such things wouldn't happen simply > because programs couldn't accidentally rely on it, so we'd get the ideal > world without breakages. We don't get that by pretending code is fine > when it is not, and letting developers write that code. Once again, it is not GCC's business to clean up the packages which use GCC as the compiler. GCC is a tool, and should allow any legitimate use of it that could be useful to someone. Warning about dubious usage is perfectly fine, as it helps those who do that unintentionally or due to ignorance. But completely failing an operation that could have produce valid code is too radical. We all want that the code of the packages be clean and according to standards. But using draconian measures towards that goal is dead wrong, and is basically against the libertarian spirit that gave birth to Free Software. It is not an accident that GPL doesn't disallow writing badly written or even crashing programs. > > 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. > > It would be a grave mistake on the part of GCC to decide that part of > its mission is to pretend code is fine when it is unambiguously broken, > and then not tell people about it very loudly. It is not broken, certainly not "unambiguously". It did compile and work in the very recent past. > I don't think we should send out the message of "GCC: the compiler for > your untouchable legacy code, not for writing new code, or upgrading > existing code". GCC sends the messages "don't write bad or dubious code" by emitting warnings about such code. There's no need to have a virtual gun pointed to the heads of package developers to make that message so much stronger, because doing that shifts the balance from merely being a good and friendly tool towards second-guessing all of the GCC users and knowing better then they do what they want.