From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) by sourceware.org (Postfix) with ESMTPS id 6EE7C3858C66 for ; Wed, 10 May 2023 09:12:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6EE7C3858C66 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=aarsen.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=aarsen.me Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4QGTmt3dmhz9snH; Wed, 10 May 2023 11:11:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1683709918; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ee3Q5h1VUIRsj8/SjIcnSDvr86xEPK679Ob/wjzjcfM=; b=SV5J48EDWFt7XFfV6duM3j0qe0ptOg4/hf4o04b7IotNq6rrTEeivNUcRDR1YAxAv5OU89 /VTY13ua86Hym2CoesS7XPzhq4+lnGQGl4tiqeM5DgbOIEAko5Z471O3RK3uvGThrMrt+s TJrgDhqh2ew3CcKP3AtQP7oK/1ZaBOo63sukyYqS7Oifyc68cHy2vykxLeyQGpuUIGeq2o 4enIWHQxBmZ/5i1QZpZzLWdlGMEcO0Pw44OMKKRPm39ep3PvxJOFijPE3wJM3JIoDxZo+v 5h4oUb8pB6XjD/z6VrYjG2n4vTNghqgsbg3fKkCuVmEh+wLRAEFx8NkOnHC5BQ== 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> From: Arsen =?utf-8?Q?Arsenovi=C4=87?= To: Eli Zaretskii Cc: dje.gcc@gmail.com, jakub@redhat.com, jwakely.gcc@gmail.com, gcc@gcc.gnu.org Subject: Re: More C type errors by default for GCC 14 Date: Wed, 10 May 2023 10:36:23 +0200 In-reply-to: <83cz38ap1a.fsf@gnu.org> Message-ID: <86o7mspn3a.fsf@aarsen.me> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Rspamd-Queue-Id: 4QGTmt3dmhz9snH X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_INFOUSMEBIZ,KAM_NUMSUBJECT,RCVD_IN_DNSWL_LOW,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: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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. > 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. > 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. > 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. Now, of course, this instance is different to porting-to pages, because we aren't talking about code accidentally relying on a transitive include or an edge case or somesuch, we're talking about the compiler going out of its way to produce wrong code and whispering into the wind about doing it. > 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. 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". Providing compatibility here is a trivial job, we don't need to make each developer suffer with tweaking compiler flags to get the compiler to diagnose blatantly wrong code as errors, or more likely, not do it at all because they don't know about this problem. We could, of course, alter documentation to tell people that running GCC in strict mode requires some concoction of flags, or we could alter it so that it says that running GCC in a lax mode requires *one* flag, for the exceptional case where code can't be easily fixed, and it's more useful to pretend it's fine and emit broken calls. We could even provide a 'laxgcc' or such driver that covers this exceptional case OOTB (though I'm unconvinced that does anything that setting CC=3D'gcc -fpermissive' doesn't cover). Have a lovely day. =2D-=20 Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZFtf2V8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy c2VuLm1lAAoJEFLClDAeosSTgpIA/1IJSIy3lwDtFvooEWHvABXv4znbZNGKV1eu HohwKheSAP47jc/jTPou0jKsOVAG2t1gg65agbRUBndTK256yw/SCQ== =h7uz -----END PGP SIGNATURE----- --=-=-=--