From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) by sourceware.org (Postfix) with ESMTPS id E8C09385773C for ; Tue, 9 May 2023 20:16:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E8C09385773C 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 smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (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-201.mailbox.org (Postfix) with ESMTPS id 4QG8ZN6pYcz9sjB; Tue, 9 May 2023 22:16:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1683663404; 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=BMlpw3jE6yNZUd29ECrk73VA1+YNOocIJyHc/KK0Sno=; b=DOAdGOqlMjAz4XvF+CO4lVFvjhOSCqo7uvgGP/OuIgZdW8oXtfKxmZID9mRownq/QYliO4 Ij4KEgZJvLOR9XHGq1Mqj/rpIuR7JY5ZV32chOSK8xfmhbq2ZlhhIxeXc4Z5KrQv9C+qLF 9mNawVno62VB9B2Kv0qJ5KcVXhllBHa6k6D1IMozEFZQ6aO4WpF88T7vAxvMU4PdZXtb+R nYlCqRCCnh5ikRSBiYLUznyBe4IPBDjycFMaW5cNPcJ2Zmj8jI7fGiExqWkBEvS6MFi88n i4K0w/t3CHOwgV3PiQwCASi6U0bzYYc4zm6c9DB+1KyZmcLyb/ojuEJThkScsw== References: <877cth66qb.fsf@oldenburg.str.redhat.com> <20230509102201.6aa2a7d14fdb2f1e7abff449@killthe.net> <87r0rp5uf8.fsf@aarsen.me> <83ttwla1ep.fsf@gnu.org> From: Arsen =?utf-8?Q?Arsenovi=C4=87?= To: Eli Zaretskii Cc: jwakely.gcc@gmail.com, gcc@gcc.gnu.org Subject: Re: More C type errors by default for GCC 14 Date: Tue, 09 May 2023 21:33:41 +0200 In-reply-to: <83ttwla1ep.fsf@gnu.org> Message-ID: <861qjpxnth.fsf@aarsen.me> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Rspamd-Queue-Id: 4QG8ZN6pYcz9sjB X-Spam-Status: No, score=-4.4 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: >> Cc: Jonathan Wakely , gcc@gcc.gnu.org >> Date: Tue, 09 May 2023 18:38:05 +0200 >> From: Arsen Arsenovi=C4=87 via Gcc >>=20 >> You're actively dismissing the benefit. > > Which benefit? > > 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. Quite simple: people don't (as easily) choose to ignore errors. You can see this in any teaching environment, and I've had such experience in many of them, so I can say with an extremely high degree of confidence that people, by default, do not ignore errors. A student will see twenty warnings and brush it off, but will see one error and diligently go back to fix it. If we tally up the hypothetical users of the hypothetical -fpermissive coverage for enabling these broken constructs, I think that we (compiler and distro developers) will be a supermajority or more. I am absolutely certain, by virtue of us having this conversation today, that warnings are not enough. I am also absolutely certain that an opt-out error *will* work, as it has before for cases like -fcommon and the G++ -fpermissive flag (naturally, these aren't magically gone, but they are becoming rarer). Hell, I've missed warnings before as they do not normally raise a flag during development (hence -Werror), even though I have many years of dealing with loose toolchain defaults. > That's a simple question, and unless answered with valid arguments, > the proposal cannot make sense to me, at least. I'll repeat a few reasons others have cited: =2D implicit or misdeclared calls lead to subtly incorrect code, =2D implicit calls lead to a lack of toolchain features like _FORTIFY_SOURCE, =2D implicit calls lead to wrong symbols being chosen, leading to data being trimmed, which can on occasion hide itself for a long time, =2D all of these constructs have been unambiguously invalid for decades, =2D the impact is relatively small (Florian cited a figure of six percent, which lines up roughly with my own observation), yet an escape hatch for aged code can be easily provided. =2D as the compiler is less informed about what code its interfacing in, diagnostics are proportionally affected (alongside producing incorrect code). =2D these constructs have been invalid for decades, and, if considered an extension, they're a hideous blot. =2D by making GCC not a strict compiler *by default*, we encourage using non-GNU toolchains because 'they provide better error reporting'. This also applies for other components of the toolchain. I, for one, have little interest in enabling that when the cost for keeping fast-and-loose-playing compilers for old (read: broken) codebases is low. It is very much okay (nae, a feature) to be compatible with previous versions of the compiler, and a prior status quo, but we should not let it hold us to worse old standards in terms of strictness. On the contrary, I'd like to hear the upsides of keeping these defaults, besides compatibility, as that one is easily achieved without keeping horrid defaults Have a most lovely evening. =2D-=20 Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZFqqKl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy c2VuLm1lAAoJEFLClDAeosSTMksBAKkNjlBih9G7ypX8Tm+66qSv7Ct5/KH2DYv6 2iuRDwsOAQDRGaeaJvUmGClfgCuP45FAQwCAMftS2ZK2cBtwZOKgCg== =7vMf -----END PGP SIGNATURE----- --=-=-=--