From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) by sourceware.org (Postfix) with ESMTPS id F19A83858CDA for ; Thu, 11 May 2023 22:41:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F19A83858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-io1-xd35.google.com with SMTP id ca18e2360f4ac-76c7dfc2e8dso33877839f.0 for ; Thu, 11 May 2023 15:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683844910; x=1686436910; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=KSuJBbi+KECtLlt8EGiRFGIQL+sY1/6JCZhWjoy43ZY=; b=EWmFkehHhNA3JsueBBJ4zFGsqPjxKV2yvIYpYwHmh5/kkAQbPxcMqT2ueRjnYBG1Y0 IoscXoHfOHoxjsIhk5b/DT/F4LnCgdD/whEd68uVRpCsklbNcu7MFqhFKmfNYvM7ld6o vUudMV24hweQcSfZcYp4zpwLgdsY/8v2EbAjQqgRniN2rGHGtj28ABhuU3mXxV2/jAQy bSvoKSrRSXpavwRe+1EUvNrFcbnV7JeXlvZ68gmf4/reW3/T6LclMDu+8tZusBo/R3bB g6bEPySVddV+WlSc78VpPzICdS8Juhzjj8kP8o26pSA9VqYdDY+bUXY0N4GcgCtTjg3b NILA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683844910; x=1686436910; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KSuJBbi+KECtLlt8EGiRFGIQL+sY1/6JCZhWjoy43ZY=; b=lcX9+s3ADWSrI/4s/E5g95XCQwKsPQ6zGsavo33ml86F7yCB+zAmZuraty5dOGzbje kPoJuG7/fa3srlWQUf7vWlgbxIhAWq4P8ti4m6Wq6SnrOsSgkD3FcRx+hpTfL2Mw+egG /b21egm/DMWgjplvK+IDR7r+NAFw9a7V2mq8sOSamFzH0ok0WwiKqCzeXEbkO3BeB4BU bjB0c6HjDfgz3//3S2H2iNVpLyFUoKgrPWCyDpZzTFgIcHKqFOr9nXHahZmL6JBEQZ5Z ZxFGkCYKmkRgCDCloX5oeRCZ4NKEX4F/XYqDvDyU9vsG8VEF6w7GNuCRZokXpqR8vPIA X80A== X-Gm-Message-State: AC+VfDz8nW6erWyiXzJbDW9CajDpUfm/LNL+MZk+NY/ml0Rc5mt4MkEY mFs6/W3PB0h9bLLd1euhwmaTwv+Z2D9W9g== X-Google-Smtp-Source: ACHHUZ7TRv3ATcji+Gd0mchUzD1dQ9eYWHCTrhdS2QDUhLCw2hM3KSqIk3l8IhaZh5soTOJ8eD8jIQ== X-Received: by 2002:a6b:f90d:0:b0:76c:5654:2f2d with SMTP id j13-20020a6bf90d000000b0076c56542f2dmr7583092iog.5.1683844909963; Thu, 11 May 2023 15:41:49 -0700 (PDT) Received: from ?IPV6:2600:1700:57f0:ca20:763a:c795:fcf6:91ea? ([2600:1700:57f0:ca20:763a:c795:fcf6:91ea]) by smtp.gmail.com with ESMTPSA id b23-20020a5d8057000000b00763da065395sm4463281ior.3.2023.05.11.15.41.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 May 2023 15:41:49 -0700 (PDT) Message-ID: <4d2af697-2f28-9e17-6b35-3a4ba19313d2@gmail.com> Date: Thu, 11 May 2023 18:41:48 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: More C type errors by default for GCC 14 Content-Language: en-US-large To: Po Lu Cc: gcc@gcc.gnu.org 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> From: Eli Schwartz X-Clacks-Overhead: GNU Terry Pratchett In-Reply-To: <87wn1fcrw4.fsf@yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KAM_NUMSUBJECT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 5/11/23 2:18 AM, Po Lu wrote: > Eli Schwartz writes: >> Absolutely! It's a very good point. It's a point that people writing >> traditional not-C in this day and age are doing so with highly complex >> toolchains they have personally written to do things that no non-bespoke >> toolchain does. As such, they are unaffected by any and all decisions >> GCC makes. But if they were affected by such decisions, they would have >> the technical knowledge to modify GCC to suit themselves. > > Upper management types performed a cost analysis and decided that it > would be more appropriate to license another C compiler. Please don't > expect that only technical ability affects decisions made in the real > world. I expect no such thing, but I do expect that people making decisions in the real world acknowledge that ***they*** (and no one else) made those decisions of their own volition. I am unsure what "decisions made in the real world" has to do with my observation that this real-world decision was a decision to invest time and effort and money in one direction rather than another direction -- and the rejected other direction was the one that would make them users of GCC who are affected by GCC decisions. >> But your bespoke toolchain did not support the code which you need to >> compile either. That's why you began hacking on it at all, to suit your >> needs. >> >> So if neither GCC nor your bespoke toolchain support the code you need >> to compile, and you must modify *something* to suit yourself, then it is >> definitely possible to do it for GCC instead. >> >> I don't see what the welcome for making these modifications into the >> default flagship experience for the entire free software ecosystem, has >> to do with your being welcome to hack on GCC for your own personal use. >> >> Do you feel welcome by your proprietary vendor, who refuses to let you >> touch it at all by withholding source code? > > No, I do not. I can not speak for my management. > > But I also do not feel any welcome from a group of developers who are > interested in breaking other code, some of which I have written for > myself, and then religiously defend their decisions. > > In short, I do not like being told what to do with my own code! I do not consider that you are being told what to do with your code. Your code is not being broken. You may have to update your Makefile to add a flag that turns off a changed default, but that does not constitute being told what to do with your code, only being told what to do with GCC. >> BRB, renaming all my python files to *.c and symlinking /usr/bin/cc to >> /usr/bin/python. >> >> ... >> >> No, the criteria for whether something constitutes a given programming >> language are not "the file extension says so" or "the compiler name says >> so". >> >> A programming language is defined by the syntax and meaning of that >> programming language. > > OK, and the Portable C Compiler from Bell Labs followed one such > definition of its syntax and meaning. > > ANSI and ISO simply define several such variants of the C language, > collectively known as Standard C. 1st edition K&R defines another, and > each compiler, in practice, defines its own. Just like there are > different varieties of English, or perhaps German. > >> (If we were to replace this conversation with a definition of what >> constitutes python, then as a scripted language, all files without file >> extensions could be python scripts. And similarly, people play >> interesting games with C files by naming them unconventional names and >> passing -xc to the compiler. File extension autodetection isn't everything.) > > This is pure pedantry. My point is: > > If it looks like a duck, and quacks like a duck, then it is a duck. > > or, IOW: > > If it looks like C, compiles in a C compiler, then it is C. Very well then, (lots of) C++ is C. But many people do in fact argue that missing function declarations do not, in fact, look like C. It doesn't compile in a C compiler (using -Werror) either. Some of the warnings under discussion in this thread were never valid *anywhere*. >> Well no, because if they are sufficiently dedicated to their existing >> code to not have changed in over 30 years then they are writing c89 code >> and passing -std=c89, and this is acceptable as far as GCC is concerned >> and their code will still compile. > > They are not writing ``C89'' code. They are writing ``GNU99'', or perhaps > ``GNU11'' code. Some people like writing some code in one language version, and some code in another language version, and doing so in the same file or perhaps even the same function. Acknowledged. I would personally be afraid to do that, it seems incredibly dangerous even if in the highly specific case of implicit function declarations it happened to work. 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. The fact that it compiles with a warning in GNU99 or GNU11 mode doesn't make it a GNU extension. It compiles with a warning in c11 mode too, does that make it a c11 extension? No it does not. >> So they won't feel inclined to find some other compiler, and quite >> frankly, if they were doing the right thing in accordance with the >> standard way to use the language they prefer to use, then they probably >> will not notice that GCC changed anything? > > What gives you the right to dictate what the Right Thing is and what is > not? I am not dictating anything to you or anyone else in this paragraph, though? All I said was that if one writes a c89 program and tells the compiler that, then they will not even notice this entire discussion to begin with. What, precisely, have I dictated? Have I dictated to you that a c89 program can be described to the compiler by use of the -std=c89 flag? This seems to be a pretty standard understanding, to me. >> What guarantees of the future do you have for anything? >> [...] > > You are arguing to absurdity. Correction: I am arguing by analogy that your statement: "what guarantees that -Wno-implicit will not be removed in the future" is arguing to absurdity. >> I think that what-ifs aren't the most productive use of our time. The >> current proposal provides for -std=c89 and similar, so the current >> proposal does not cause current GCC users to be unable to use GCC after >> the proposed change. > > Perhaps you must try writing a program which strictly conforms to the > Standard, since you seem to be asking everyone to write in such a way. > > My point is that there is a very significant body of economically > valuable code written in the dialect of C actually implemented by GCC, > as it stands right now, just as there is a significant (albiet not so > much) body of traditional C (K&R) code. > > If GCC is no longer able to compile such code, it will attract the > legitimate anger of its users. And making users angry is not productive > in any way. Many people write strictly conforming program, and consider lack of conformance to be a coding error that must be fixed. It seems like a wise endeavor, frankly. I am not sure why you are challenging me to do so as though you think that I will be incapable of it and therefore be forced to concede that toggling the default diagnostic for very old code is a bad idea. However, it does appear that we are still stuck in confusion here, because you think that GCC is no longer able to compile such code, when in fact it is able to. >> If a future proposal causes current GCC users to be unable to use GCC >> after the future proposal is implemented, then, and only then, should we >> worry about whether it will be possible to use GCC. Then, and only then, >> will a threat to prevent doing so have actually materialized. > > Parse error. Maybe I was unclear, allow me to rephrase. If a future proposal to GCC results in GCC becoming unable to compile some code, then and only then should we worry about the existence of such a proposal. Since no such proposal has been made, it is a slippery slope fallacy to argue that ***this*** proposal constitutes a threat to users' ability to compile their code (even their implicit-function-declarations code). I do not believe it is reasonable to: - engage in tons of argumentation and insist that it's a bad move for GCC 14 to change a default and add a flag to get back the old default by claiming that it would be bad for users if: - GCC 16 deletes the flag for getting back the old default If it is proposed to delete the flag for getting back the old default, then and only then do people with old codebases have a valid complaint that GCC is becoming unusable for their purposes. -- Eli Schwartz