From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) by sourceware.org (Postfix) with ESMTPS id 5F828385C301 for ; Fri, 12 May 2023 03:07:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5F828385C301 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-il1-x12a.google.com with SMTP id e9e14a558f8ab-33131e965a2so18970115ab.1 for ; Thu, 11 May 2023 20:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683860878; x=1686452878; 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=n8ImD2esw895spNCfIg14oaL3SGOiDeGD1NHsKfpCyo=; b=iaIMwJlljVxOa0EwU5rqR4Gq6XTN75Wx1b9SKqA3B/O3oDuhCwF2AmKhIwZLlg4xwa gAhiQvpYt/4RUewh/s7njD+59VevbMxbeGz6m/uuO4pZmpvFFHd/HP8QfEQxW97OyIHu gJG/X7vJxdEoOwe1ttsdb8LbKSIX7jBAjy/4a3ON1XaIFlhAds8qSzwIs1D9wjBVcEPa oMKOsghY2ZO/4HQK02iktQMkFBZYvm9+8JLM4AC3DGD5OJ4MGilfqVsF4YEQ9AL6sZn7 ku6QxRav5gxsXMPNlUekvAJsTzbEuISmqlI3FL1WIg3gz1Gc7iwiXJ9bRIeI22gnmZ3J aZCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683860878; x=1686452878; 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=n8ImD2esw895spNCfIg14oaL3SGOiDeGD1NHsKfpCyo=; b=CMSez4PgYfU0I3L0Dp8YxVqryOL5iIwwe635Y0Y0vZkKVNFd9MR1K4gLMy17eycLgi iPM4c8HLGE7SKl+HpoPzKSozm5xJm651Zo6TclZgxKqvC099XARt6xnjMw/kfIPPXEDH rsGVGjYDM3W96FJvLshxaAho1XbjKkbBh1YFWP4zVNXsk+96tToFo7xqJBOLPjXaqDqE ojWDXbL+yLuP4b0r+NSurOZosTEoRj1Ik5Aljwv6Rn5UmyyeKoSBe5TJygqpqjL43J3O OzYvWrstuhKm0xaES6+t8lXOV6bdkn0+WQLzn9jy7udpTNDrj9rWLEnBU2a/bvjDUHP3 MrWA== X-Gm-Message-State: AC+VfDxWRn5BaW0pidiH60/mN2mgd5+mZvsrMCVowBWT+9zidE5jPRFl u9NLYpiZkksi/bAkV2FRtvO7rSkame8pIw== X-Google-Smtp-Source: ACHHUZ6xjMRWBuF6hXF4+1F3EW1itAC6MSCJHlXKTY+JirJnr7iCyKFY4UvYnlZipLk/iywsWNrhdA== X-Received: by 2002:a92:c890:0:b0:331:1f0e:79b8 with SMTP id w16-20020a92c890000000b003311f0e79b8mr15740136ilo.0.1683860878064; Thu, 11 May 2023 20:07:58 -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 i14-20020a056638380e00b0041627abe120sm3166817jav.160.2023.05.11.20.07.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 May 2023 20:07:57 -0700 (PDT) Message-ID: Date: Thu, 11 May 2023 23:07:55 -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> <4d2af697-2f28-9e17-6b35-3a4ba19313d2@gmail.com> <87mt2ab8te.fsf@yahoo.com> From: Eli Schwartz X-Clacks-Overhead: GNU Terry Pratchett In-Reply-To: <87mt2ab8te.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,KAM_SHORT,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 10:08 PM, Po Lu wrote: >> 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 > ^^^^^^^^^^^^^^^^^^^^ > > My code is being broken. There are thousands of Makefiles, Autoconf > files containing configure tests, and so on. 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. >> 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. > > That's GCC trying to tell me what to do with my own code. So you concede that GCC is not telling you, only trying and failing to tell you? 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. 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: """ 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 importantly, GCC does not agree with your analysis. 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"? >> 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. > > Except it does? Since the compiler is defining behavior that is > otherwise undefined (i.e. the behavior of a program after a diagnostic > is emitted after encountering an erroneous construct), it is defining > an extension. 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 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 >> 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? > > That people who are writing GNU C code should be forced to rewrite their > code in ANSI C, in order to make use of GNU C extensions to the 1999 > Standard. 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". > The reason I asked for such a guarantee was that two important options > were in fact removed by the GCC developers in the past: -traditional and > -fwritable-strings. So there is not exactly a good track record of > keeping useful options around, after features are made into those > arguments. [...] >> by claiming that it would be bad for users if: >> >> - GCC 16 deletes the flag for getting back the old default > > I'm sorry, but this is what people have seen repeatedly happen over the > years. Thus, > >> 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. > > Being sceptical about the future is perfectly reasonable. 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. -- Eli Schwartz