From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic307-10.consmr.mail.ne1.yahoo.com (sonic307-10.consmr.mail.ne1.yahoo.com [66.163.190.33]) by sourceware.org (Postfix) with ESMTPS id ED3063858D39 for ; Fri, 12 May 2023 05:57:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ED3063858D39 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=1683871068; bh=A66MTqRnVT66+nrFJasY6650Hz0Yq9uPFGnPJRDNu+s=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=HkD2eTEjDzB5RfYjW7j+moxCQBRp/WZy8cViZ/VaTOKc5FvLcH4W0cF42d/WYr30ldnyZQ2isGw7FQR8p2oE0KPagkOmKX98+DRfkvIdyYZDNJO8NPWIE2GMhiFKCMAAlWf7arGXX/vcVSaIPia+Nur5+I4X2SqP96/yDTC7xkicUPdtSsB4GTr9OHr1aYsC2N/Nj0TNK00yn8B540oYLFb96I6lIjtVy/Mhw6Bk07pt/wSr1/ZD16kyfM2FFT48RRvYtc0QZ7lEIb/09SWn9myF0KJb77nszltJOz9lcKow9Qjj0VggkxwB+N2DaxvCYczeBJrb1zENC2xoXKsnJg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1683871068; bh=v4on1tWLZumzC5vovuq+FSjHw/myoQCU7lFNZeqYKfO=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=V28QHb/tenkOCRMyBNgMNfDqkYY//2UGxaAP23L5r+uPyWsSJlCQZMilG0Urv4YZ/gN5iE8STcH3RGlkuAuTyJgLbPl494IbvOUbVINlkqUMPdbWhXIPXCqkND/P0m6WYNJTxnSgPphWdn7WxphP3oz5qmuufQFnNXGvBIWa/yZ5f5AbxfcPfLeJy+OrUqAKZyPN3iI4K5+3ENXlBmzsBBj+BKJcj3o7yQuZzljl2gLMws5BzgndPwZLXN1rJTqsp15sdtgEG5/7yWzgqL3dV56p5R6fI0ihs8kKPbyEbMuuxEkHv4Q6LSDdSyUUQiZHJFXFu5Q9fgadd2Zv3bh3yg== X-YMail-OSG: 3o.I7fAVM1n6eITAcJcksMm8fgZ8tW8FhMiiEafH2u5eVEtAr1ci47Nr11ZPMYp URnicbVAZ0wPF7xhcTKW.WRG8qqUvV.e61vRDj6LyM9ZGwD6hOiX6lWxNfhSb4tVqIouf8_S7QIs eizktCaii9soeDwfUN_C3LV4ArzfvK6BrpZhtq_uwMdmrSk3tvZzPUq3CpOmV1A477dKLx5t8461 6T3A6JZnXXodW0a_P58zYTgpZMglTlVt6tTo9kW0sYUQXTgyY9ku2j2jdI6ftdKVxnADdHWjYdCu O27BCNkiOdoXpQfmwgf9vGb1hO_kvYfuTkyAyXnLSC4t_w6JsIif0bGYXtbQU2L1jKUEF7fBD7SD KJPJGGIvIHjWGfzaI9kjWNFIIeExIWLlfkJAlScP8xhAlOJ2mlePNl94cH0_gyPB0ysf8ESCROkx iGdxHxxzkrViA5ZOIhozwcec_00NAjN5n54Ox4wIxdiXtEGl1Nst0cgJaNCf38fabHH2L3vBbvpg 66c4Q72zZOxi6TnIvJOY4lKrVGW85hP39M0HxwKan.5.rXNV4v7TM.mxWfqFp6YUgdIygIj3NEAg lQkr8m1I5SvW0jCK6PpfoI7tM26B0mtvmu..ahLPCNK5iWQ.YI400t0lH09IRlC.bkKprYtMA7Ml isLyGtcsjsZvF_eBln6Gla1d_cEhgKfPBJB9gptDyGKx81SGA8gyF5AzpundhgVTqOfRWi5TPygn OJxADRClVkoQORjPmyuhuE6kphBOIcvab4syEmjeCOQ3DdLx.Fz2PvwdhR5K2h7646cXISbpFcRo TQEY1IV4tnhqEZPynp4ZXQ.kfOwxhP2oiGdpFRP7sY7KYrbWJXAPsxjFPLoWwQBrAqYdebnOjDPC xYpuPct_lz_vcpB34VOgRr85WG4PgNqXsuWo_6O.dS0aPtdY0JxIFoNdsy2qP.VcdGkhayIhK.Xr h7n3K9Cp2vhxzxp.67.CeRv4n1f7mlnFPlGBqfjXQRfpIqVrLS5HCdCty13MGQIP5.vsUMzvYDXS gwBr_H08GcAU1R0MQ5S3e6UFzn1FLs1WbnVq5UX1NqJjgv0oIA53uFIK_n5RSQwSfbLNsEhIDeVH _ZaYwiw4ItKcdjELbEZ91PBIM5mhBKFkNteXxzhstg3EuJ8aKxAlGvE53zGafstHi0o0NOaS2M3z M_xR9NGIRUFs3Xt4gHMYkUIrcOTrlp_4y4yPii6xj_CONMsIMA2yGmx8wPjWjhdf6MIS.W_obQzS mQrTG7pddgxwR7oMz4ARKQtdfevkj98DYvkW9oEzlERrfaDJ_O2q6URxOqDHL6fNY7pGjjX1wv1v qCf0Cael8PUfIzLJX0Xu9DfF13cfgvs_Hj9tb1cVdrPVGAllMzmgGJoUN4dGHpYLbDPBkE93VIVY v8IHnWNsGP.xYNp.ovOayeXhK29Gyr_HmNjKf_ouH6HaJZo8Dfc4.509NOKIdOxA7dMzkJoxBr_Y GVdmr26I1QT0h48o.hrhtYZf.hAR06Qgbt.iiqp4oD1ebYIZPP5RbnOVCnTa6i5fIYcFT6vY4Gj4 SiA6YFGS3oOIXHVMaSzRGEBBf3xb_0l8qg3Ciz6iAIQsqbMp62AeG_R2L_0eThTzXZ9wcr6_BNKW lovg4sPOkbAOyrfWoSzGDFzB.RBhIRnUkuxxiUXlbWGjwOgfHo.V17gNYo518RcmnVifm.aUDqLv MsGcc7QcYPwsKdC45dYdoI.t38DDr8s6b2rpq4h5GgkPn5thCG5WGAzW3AWec1jJAd4UUT0RRsWz CTwSmOXSsruQ_HWsuQk7s8CIxf2iBcQohCwWhHdPTsCs70Wx6xcbYngWOcwU0aKsgjeHVqKyBzHB MOhl5eso1T5rIyh_1bpffyORm097DUTZ7lUrvgscEKxmhEFDqw3qiQAaMWEdn839lVRA_qClhhVN ksk.bfSJhjd5doKixxxm6kUhS9UaoprAH7JJD3YOkgIYTxarRslFEs5QWkr3.yOFG_9k8C3BI2s9 bIfcLv4Ncp.2fgQR1HOGAWn_taW6Ac51XWQYMWpOxy7QAtj9JtgPgoumWI.UzSsKNhQyVHNAybS3 e4JiZ73pdW962viw7IGk0aUOUG1Kk40rTsTWnlNGPOC2JlpYUvrBFS9gVpWjfpzgFvzKX8vqxqCa 7tsLuo704av3Bf4pMwkgB7feVhWj.9QMSNLovDlNaLR0w83uQR9GjFGiGrKZ8TVMQRQggHA2eUas QVc1qmaNwROdPNRUCZLd3Ml0jHAhITktXLOTK1oQTxA7rFojE6xebue8fTAmWTx0EHU_oPIxQ X-Sonic-MF: X-Sonic-ID: 246c4aca-8746-4ee9-858c-109c43f68774 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Fri, 12 May 2023 05:57:48 +0000 Received: by hermes--production-sg3-748897c457-v5xjh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2cac98c19073e14fbcfb76c6624650b2; Fri, 12 May 2023 05:57:43 +0000 (UTC) From: Po Lu To: Eli Schwartz Cc: gcc@gcc.gnu.org Subject: Re: More C type errors by default for GCC 14 In-Reply-To: (Eli Schwartz's message of "Thu, 11 May 2023 23:07:55 -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> Date: Fri, 12 May 2023 13:57:39 +0800 Message-ID: <87h6si9jn0.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain 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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,KAM_SHORT,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: > There are ***not*** thousands of Makefiles that have this issue. But if > there were, then Makefiles are very easy to update, and only have to be > updated once per project, not thousands of times. So this is fine. You > may have to update your Makefile, but that is no big deal. > > It's still no big deal, no matter how much you dramatize the intensity > of adding a flag to your Makefiles. It's extra work. Why don't I just write: extern int foo (); above each of the new errors? That is just about what anyone will do when confronted by these new errors. As a result, you have not ensured that any declarations are correct, but instead you have annoyed a lot of people and lulled yourself into a false sense of safety. > So you concede that GCC is not telling you, only trying and failing to > tell you? I concede that you're playing with words. > Great, so what's the problem? If GCC can't actually enforce it, and even > goes out of its way to offer you options to ignore what it's telling you > to do, then maybe... > > ... it's not telling you what to do with your code, only suggesting what > to do? > > So ignore the suggestion. Which is made annoying, especially when there is absolutely NO guarantee being made that the new option will stay. > I'm not sure what this semantics game here is trying to say. Is it > ethically and morally wrong for GCC to try to tell you what to do with > your code? Is it undignifying to have a mere machine go and lecture you, > a real human being with a consciousness and free will, what to do? > > Because if that's what this is about then I think you are taking this > inanimate object way too personally. > > If not, then I am simply entirely unsure what your objection is to being > "told". > > >>> Because that's exactly what is going on here. Features that were valid >>> C89 code are being used in a GNU99 or GNU11 code file, despite that >>> ***not*** being valid GNU99 or GNU11 code. >> >> How GCC currently behaves defines what is valid GNU C. > > > No. Absolutely positively 100% no under any circumstances whatsoever no. > > This has been explained multiple times by the GCC developers. e.g. > search for references to accepts-invalid. > > """ > They are bugs where compiler accepts something that isn't valid in > the selected language nor considered valid extension. > So, after the fix we reject something that has been accepted before. > > In the last few years (checked what was fixed in 10/11/12/13 releases so > far), we've fixed 12 such bugs explicitly marked that way: > """ The Standard states that each conforming implementation must be accompanied by a document which documents each and every extension. This document is the GCC manual, which makes reference (not too clearly, however, which should be fixed) to both implicit int and implicit function declarations, which are allowed in C99 and later dialects of C. These constructs are not bugs. These constructs explicitly defined by GNU C; since a diagnostic is issued, GNU C's implementation also conforms to the Standard. > You cannot, and are not permitted, to define "how GCC currently behaves" > as "defines what is valid GNU C". No one agrees with your analysis. Most ^^^^^^ I'm not a person? > importantly, GCC does not agree with your analysis. For some definition of GCC, which is apparently you. > It's a wild, wild, wild claim to begin with. You are arguing that any > bug, ANY bug whatsoever, which qualifies for the title "how GCC > currently behaves" because if a bug is currently present, then GCC > currently behaves in a buggy manner... > > ... any such bug is, ***because*** GCC currently does it, now part of > the documentation on "GNU C", a language dialect with documentation. > > Can you show me where on > https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html the GCC > documentation states that "C Extensions include anything that GCC > currently does, no matter what, no matter how documented or undocumented"? I see: `-Wno-implicit-int (C and Objective-C only)' This option controls warnings when a declaration does not specify a type. This warning is enabled by default in C99 and later dialects of C, and also by `-Wall'. `-Wno-implicit-function-declaration (C and Objective-C only)' This option controls warnings when a function is used before being declared. This warning is enabled by default in C99 and later dialects of C, and also by `-Wall'. The warning is made into an error by `-pedantic-errors'. > The concept of a language extension has bulletproof meaning. You cannot > get around it, redefine it, pretend that something is when it isn't, or > otherwise disagree with this bulletproof meaning. The concept of a ``language extension'' is not defined anywhere. Instead, there are three kinds of behavior not precisely specified by the Standard: - undefined behavior, the behavior upon use of an erroneous construct for which the Standard imposes no requirements whatsoever. - unspecified behavior, where upon the use of a construct for which the Standard imposes two or more possible behaviors, and leaves the selected behavior unspecified. - implementation-defined behavior, unspecified behavior where each implementation documents how the choice is made, and is required to document that choice. If the translator precisely defines either undefined behavior (in this case, erroneous syntax) or unspecified behavior, then that definition is commonly considered to be an extension of that translator. Nothing gcc.info says will change that. > The compiler defines an extension by writing about it in its > documentation on "GNU C extensions". > > Anything else you have to say on the topic is automatically wrong. > > Language has meaning. *Words* have meaning. The word "extension" has a > very specific meaning in the GCC documentation. You can read all about > it, here: https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html GNU C documentation does not decide what is an extension and what is not. In any case, if (gcc)C Extensions does not mention extensions currently implemented by GCC, then that is a bug in the documentation, is it not? Documentation is supposed to reflect what the program being documented does, not the other way around. Like the Standard says: An implementation shall be accompanied by a document that defines all implementation- defined and locale-specific characteristics and all extensions. > I did not dictate that you have to rewrite your code. You are replying > to something that has no relationship whatsoever to any form of > instruction, telling, or even ***advice***, and calling it dictation. I > reiterate: this paragraph was me ***observing*** a fact. That fact is > that if someone happens to do X, then they will not be affected by this > discussion. > > (X is, in this case, "someone wrote ANSI C code and also chose to use a > flag telling the compiler that it is ANSI C".) > > > But, furthermore, I would like to now clarify something anyway. > > You are not writing GNU C code, you never have been. GNU C code is > defined by the documentation for GNU C: > https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html > > You may take this as me dictating to you that you are not to call this > code "GNU C". Really? Then why is __GNUC__ defined, and why does it compile with `gcc'? > My opinion on this is (still) that if your argument is that you don't > want -fpermissive or -std=c89 to be removed, you are more than welcome > to be skeptical about that (either one or both), but I don't see why > that is on topic for the question of whether things should be moved to > flags such as those while they do exist. > > If they want to remove -fpermissive, or -std=c89, out of an > unwillingness to provide compilers capable of being instructed to accept > and compile your coding style, then they will do so regardless of this > conversation. > > We might as well assume that the GCC developers are honest and truthful > people, otherwise it is *definitely* a waste of time asking them about > this change in the first place. How honest and truthful they are does not reflect whether or not the proposed new option will be kept around. In fact, I observe that none of them have committed to supporting such an option indefinitely.