From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic304-20.consmr.mail.ne1.yahoo.com (sonic304-20.consmr.mail.ne1.yahoo.com [66.163.191.146]) by sourceware.org (Postfix) with ESMTPS id 59C8A3858D28 for ; Sun, 14 May 2023 05:38:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 59C8A3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=yahoo.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684042725; bh=FrwQ1qnLD2XNLSLRmnhWQbIvJ2wdUXmc/I9G1ZGdDAs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=N2aSHo91+RMMv6qjNd2jA11WbnhGCCcrIZMRTq3Y6CnA/6y9F287x5oKjPl+/X16ixx9gktxhHiRWcxvpIJeIU9FHN/DIZfxE+ljQUDZHMm+GVc1jKGl5MtkTrPagtqUPiTWPfytJSlsroyTt/hZN3TKE5GK7/3aLq/7dw1d8NXFZIaaP96CvPvAD40ryGOP3meLYGPbweCZens1OQ1cjnchoDj5GZcbsZ1NqpUl3VYFQPW+yXbb8W9LiuiZL28QIwOdxWyw8aILj/nY9QCs2vpuaNnW9sjhDL8pIRMgVU3vAcEoBCaxgumZnaKMHF08ghp/LLa+lCV51ay0rXdu1g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1684042725; bh=UOnpDEgoVb4eW9HE3tNjs0BtwJPGnPMQPnDunJFcYnl=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=DAwE2wIh8dtBPk/yM8qBG0dBY+yDvjko/hOCOcYcnzTtPL+j2oFQgcE5W/4dMt4uk5cp1E1SqGjYCG9GvgzwnBY5zlQZhks29ajCetXMOB3UZ3dCMk0VUzqNJ/rE9Eh6ckagaImpe/5mucrNWQ/uJK53fCUZ4QYJTxPWWHJ43rRZXClrSvQKKRhOorMcFfdyQgIKGuAHmETwNuyMNuqLg31qlMKHjrScTjvrciMNMthBnZlY6X3+lTkLW1oGvWGZ3OxB1FJT8sDOKptLYmj1V4RY63oSlSDKs6EEFrC6JKyf+Hl4XttGdBT3o9MZAIEA8q0El2qmS2aurq/5QocUAQ== X-YMail-OSG: UScVfmYVM1m6Os.D3HsoPXoN6mjXTj_yn4HbPHYig62DcedUIeAWxch5xHABXXz 6TLipNnAP7XpM_.WaoR5D72auoekmbUEjIsa.I27FGWGYMccfQPcVUSKrDu2r9YKULTvhtVeeIw3 09MnzQEJnp67tA6VcQaHpU1FgCejkv.S7YaHoscxZldyZ7jWMVf5CpV0sxQ_ieIy9jKRV.RbY5mb pRKImvWdYJFIJIkjIw.xniUEFSlIRdKt8qURrTd4Dn5J.WrFEYNnFIYxwGxGqWTq2eZyNsL.OcFV H.uUzN5bFBI5vLZRyRMQZyK6YymKZy3yBuNGoTZZAdGSYR2lHbmdCR4qkw9vt3fDO_vxsT4aezUR P4RBOy66OrJzZ.M66LSedLxRzbGcUFNYR8M1ZLmDjFeVwPXrxq_BPhcjbCGS0J3x4U.aA5x2T19S XP2LGilgEOafSk8qLJXKoqhBbb5vZQ5gN0dVMmHfGBGocmOG9oMFTs0_mNvdAsoXhV1HbM1pGz.o KT8vI8o7hQbRRL3TgEmVeqZO.FmVAI8fbbXFJ2ent5YGNplVU6Ike75zq8bjZt_xJr2qbyMGG2nP 3t1vGedrvmTRoNV.5E.l7TMmO2Rbkc5QHkWiZ2AH.3iacRa0LEHWqxc6apP89JnyqKSQH033ilaW UjDDU9LnBNQf0iWf.t90r.oHzbm7IuuT7BMd6KvGuaLi3HVeu8TypCABjTzL9EvGfVDHt_CgeOVd Oy6p1j3P1NrlKugB8UtsT0xncP5Ja0hSS5RMeOmVoT8p4GdpSeWZcxymjhJIJUNegGe1dLPFCeye uxTArJW8NVA.lAATAxruO1SHkiB0K400MPE8pVc1ZamH6jgiHd1ov.FbV9haod8CTKtBDohbTLMZ LXhBnW88CXHP.aEbI8PcW9SFwMB.TqR8U1f4VWPCD7Ny6wvkIKW3s8Yzhh08qoyqDTeP6K.0ScSu ufHaRi_eNHt5IduggMes7cY3j2ln.uOQz3IQ0hHAJY.J5sbrY3w99Zgi5dCXUoHq91aZ7CXMRiQq 2dhQLLJBiWOvzy2edBcGlRmvhnmMVRNpwkvpEHq9Hgy_RqZ8lBhCXYYPhcuf6VHyjrkU8jo0YQcz pwpiU6hzeY_ciY4nHXJPmYV63tagIu8hwYtna3OIf0CH8T1c7bfocF250mjSQkmBNiYqS1uAalJw 8zZ.jxH1qi.gF95W0ltGy3NDor71OR2opuirvR0NPa6XJY55OmJy8hrUd9T_SmbfkoJ1Tq43C_1l EASfHJ_fS1bLe4NBRnjKTaSrrDfvzvUH1i5Uiurs1BvLAJk685NvU_XBGnVs9b7W2TOVod2EgzHK Rncd9nEd62jtsVrEN8_HIWoPbd9GLGBREudpfbfi9tY0GLS1ki61JtN1opBxmvYprYv1G6WIbFBR Tq2yNz7sWwBq6MUmkZEgXJShihdmY1FEV8OUnfzBNZ.x7Eepje2Uhgma9y6FpIUT.laSFSAeDljC Hz864cnguIjsSMlNmCeuK7_cAuSO6hP1k.dyB42qo_9Mw6fn1.6EbHQVbnAEGkgXBS4WORrFtdK5 KGD29rEWZegRYH7umOH_c.s38zIkV0EyiiT5jshywGgQ.7ue2NbbDPzzkW.CMkp7hVfjeVQZoWF1 i8dU2Mn1i25xPvRxHgVdqmhgd32jq69SgN9f6qM9hX4YhiVSPoXeTTFZBPBm.udPqc4fEBXMfPmR KBiFZAvfvN2IAYQFjhZG9d_PmCGTfmYsqgDeO1FFvegr_67nKuLAO72MN_AtqYr1bRgwca27GIYn VS5yKjSt4KG797unw7UyyorGjm95943m5t1gkJcpE8rhsjVoSsxQf1G5ngH5G8ysuiZuFyy3aOfh tpkhN2hysxFQbssxr3fBpRbbyRafcYfjwvOy9QXi4ZqS0evLXxvXIsKwz2IpaXfTRaPTuz1nfmIA VlFyqQM3X41BJ0d1SIVaYHbx0MceYw8O5QGyHRQf2RgYi2Jm6T8tK5JDz8PeWcmwufVr3LGPBZaA PnC_AKUWWyUjutT.kL4OBGiP_Nj4vYCGpCw.8zh2CnHYgqYvVPrkApIHJylPi3I1pAl9EJ1NUktV U6ufm7uMIk.FldYfPBrJXBZ_7UsGEEoIXglfHyiiMPlX1kLRiLLUruUmVM1pFDRJOJ7ewLnjrVKu uNRCSlFTDG11d1zBDsf_5VkxGa0NyLsdxdWpGV7iaLWq9LKTUJ8YRzYuw5WeWysiAaSKgj3dSj0x j_h1RDQY3vs3nNU2Y8CRl3_NQkZ.HhRhi_13LXfAxZdflzDL1jj8VJ9E58pPJgBaj X-Sonic-MF: X-Sonic-ID: 36df4641-1c26-46c7-81ab-1124d5c5b4bf Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Sun, 14 May 2023 05:38:45 +0000 Received: by hermes--production-sg3-748897c457-6lgkj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0e3ec3fd5dbcb19bdf0d3bf04823e288; Sun, 14 May 2023 05:38:40 +0000 (UTC) From: Po Lu To: Eli Schwartz Cc: Thomas Koenig , "gcc@gcc.gnu.org" Subject: Re: More C type errors by default for GCC 14 In-Reply-To: <80defba2-5e0e-7e67-9d17-94e676716dd1@gmail.com> (Eli Schwartz's message of "Sun, 14 May 2023 01:10:03 -0400") References: <87mt2behdl.fsf@yahoo.com> <57238276-5966-98d6-d5f0-f5451013ed17@gmail.com> <871qjned25.fsf@yahoo.com> <67e65b41-5400-d1c2-9f43-f94d0ea7da9b@gmail.com> <87wn1fcrw4.fsf@yahoo.com> <4d2af697-2f28-9e17-6b35-3a4ba19313d2@gmail.com> <87mt2ab8te.fsf@yahoo.com> <83bkiq3umf.fsf@gnu.org> <87sfc18z66.fsf@yahoo.com> <1cb56b16-1ee0-e233-30f2-464c30d19fd4@gmail.com> <87y1lt6ouy.fsf@yahoo.com> <95ae59d6-097b-ebc2-06c5-b74a0544a2cc@netcologne.de> <87mt287p64.fsf@yahoo.com> <80defba2-5e0e-7e67-9d17-94e676716dd1@gmail.com> Date: Sun, 14 May 2023 13:38:36 +0800 Message-ID: <87y1lr5v6r.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.21471 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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: Eli Schwartz writes: > GNU C does not define any such thing. It may happen to turn out that > way, but that is not the same as defining its behavior. It is. >> Nor does GCC conform to the Standard by default: while it is okay for a >> conforming implementation to translate programs relying on implicit int, >> as there is no way doing so will alter the behavior of any strictly >> conforming program, it is not okay to reserve keywords such as `asm'. >>=20 >> The following strictly conforming program is thus not acceptable to GCC, >> unless GCC is operating in standards-conformance mode: >>=20 >> int >> main (argc, argv) >> int argc; >> char **argv; >> { >> int asm; >> return asm =3D 0; >> } >>=20 >> which shows that debating features based on the Standard is entirely >> pointless, as the Standard allows implementations to provide almost >> anything it prohibits. > > > Sure, all I have to do is tell GCC to act like a C compiler. > > > $ gcc -std=3Dc2x /tmp/po.c -o /tmp/po; /tmp/po; echo $? > /tmp/po.c: In function =E2=80=98main=E2=80=99: > /tmp/po.c:2:3: warning: old-style function definition > [-Wold-style-definition] > 2 | main (argc, argv) > | ^~~~ > 0 No, all you have to do is to tell GNU CC to compile Standard C. But what's being debated here is the behavior of GNU CC when translating both Standard C and GNU C, so your demonstration is almost completely pointless. Btw, try to compile any program using inline assembler, and you will quickly find out how many programs depend on the (gasp!) non-conformant behavior of GNU C. > But I don't understand what point you are trying to make, anyway. The > Standard allows, but does not require, implementations to do many things > if it so chooses. GNUC takes advantage of this when operating in GNUC > mode, when also documenting GNUC features in the HTML docs. [...] > What does this have to do with implicit-int, which is a constraint > violation? Where in the GNUC html documentation does it say that > constraint violations applied to Type specifiers have been carved out as > a GNUC extension? As I said, what the Info documentation does not say is completely irrelevant. I might as well ask you: where in (gcc)C Extensions is it said that the documentation describes each and every extension and aspect of GNU C? The documentation is supposed to describe the behavior of the translator, not to specify it. > It's not a GNUC extension, you cannot assume it will work. It might work > anyway, but that's a matter of luck. It _is_, regardless of what you might say. > It is unclear why you are overly focused on implicit-int, to be honest. Because there is a point to be made for discouraging implicit function declarations. Certainly not enough to make them errors in GNU C, but enough to justify their obsolescence in the ANSI Standard. There is none whatsoever for discouraging implicit int. Its obsolescence and later removal was simply the act of a overzealous Committee, deviating too far from its task of standardizing existing practice. > But your arguments in favor of implicit-int aren't very compelling either. Tell me how?