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 059873857031 for ; Thu, 11 May 2023 07:38:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 059873857031 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 [10.196.197.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-103.mailbox.org (Postfix) with ESMTPS id 4QH3fr07bNz9snQ; Thu, 11 May 2023 09:38:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1683790724; 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=uX+nptJ2m4WIo4QhzdQVWkDTt+U/yLxmV8boCxM4s7E=; b=YTsqdfk+lUee6ptto4ttRMIXzI0Wjw/qYCy4dU+4Fev7CRY6IgMfbGC0dgE2yvuTBkNkA7 5GruxyXeR/kUoeQx2jA/o146kLNyGKxSrotUOt3LXuCoHK9wXDFdkQfOF6W4/G63wjpBMw Ev4VQPAYPiB+bXhgNffEFZCcmT7m4G+QE75S4RC4w+u5lI9GHW0vA86kq+1HGX2pp+KWLP V09pV88d+BXhXLxC/GSNGrs1aQeeHjefMpm1pMxFbGt1t+b+1HS1sa36xK77I9DaIVVNNw 556PoJMDU36B7Zfr69LwLZE5uHSjopT3sdlzd7Rzv00Fvvd3ln57wb0+S3HrXg== References: <877cth66qb.fsf@oldenburg.str.redhat.com> <87fs83fymj.fsf@yahoo.com> From: Arsen =?utf-8?Q?Arsenovi=C4=87?= To: Po Lu Cc: Jonathan Wakely , gcc@gcc.gnu.org Subject: Re: More C type errors by default for GCC 14 Date: Thu, 11 May 2023 09:36:32 +0200 In-reply-to: <87fs83fymj.fsf@yahoo.com> Message-ID: <868rdvnwqo.fsf@aarsen.me> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Status: No, score=-4.3 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 Po Lu via Gcc writes: > jwakely.gcc@gmail.com (Jonathan Wakely) writes: > >> This isn't "be like Clang", this is "diagnose things that have been >> invalid C since 1999". > > Only if your definition of valid C is ``strictly conforming to the ISO > Standard''. I doubt there are many programs which fit such a > definition. > > And anyway, GCC accepts many other constructs which can not be used in a > strictly conforming Standard C programs. For example, the use of dollar > signs in identifiers. Should we not also reject those, identifier names > with external linkage longer than thirty two characters, hex floats, > arithmetic on void pointers, zero-length arrays, statement expressions, > and so on? None of these result in a whisper-level warning before a severe but difficult to detect breakage. >> Accepting invalid code by default is a disservice to users. Those who >> need to compile invalid C code can use an extra option to allow it, >> the default should be to tell users their code is doing something bad. > > The code is conforming, it simply relies on extensions to the Standard. > Implicit int does not break any strictly conforming program, so a C > implementation implemented it continues to be conforming, along with > those programs relying on implicit int. See this wording in the > Standard: All of the features in question actively break programs (because they allow entirely wrong code to be emitted). > A conforming implementation may have extensions (including additional > library functions), provided they do not alter the behavior of any > strictly conforming program. > > You are not trying to reject non-conforming C code. You are, for better > or worse, trying to impose your personal preferences on users of GCC. > Let's debate the real problem at hand instead of using the Standard as a > boogeyman: namely, whether or not disabling implicit-int in GCC 14 is a > good idea. It is. =2D-=20 Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZFybf18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy c2VuLm1lAAoJEFLClDAeosST0/oA/3jPKbLYBkWdO9ceHituDDabDMhM3loRzxb2 a72XeK5xAP9Fj+9rA1tSY7xq6aelbwBMBrWqndIUeUdChQGC7gkPAg== =gFeq -----END PGP SIGNATURE----- --=-=-=--