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 5B438385558C for ; Fri, 12 May 2023 11:49:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5B438385558C 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-76c5c50ce9cso107170739f.2 for ; Fri, 12 May 2023 04:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683892141; x=1686484141; 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=Z/0fKyKc/tyHGAvUMiEABkHz81kuw978UPg4O7+vJhA=; b=lWlNedPj2H1m/Spxbj16A6SWgJD8Wmhyl3ANfkgfU0UwolLmgbqc5/wxFj+KCQ/F9n iIBxtV8cnq6Wm2ssEW8G+t5scRs3eDzQHMNx3q035bxxOlmWaYJu3OQdjuxrGZXuHqRi DTZepALFSrxbtnl0AjhfnC2/OpXajtQieKnnvQL7IBGwLhLgFTDvPzZMdFyQj/632R88 todeTPAVqMrmbCV9waU6eiPpL32nfHtpKEJdxJuBThDrcp59IHrnVy2z7QJkvkY4i/Gl ppFBmdFCacsuWCTyjTWhiLiNAHbid6tvmrgYsKRPSNGDE8o7ohbxJo9W9NKswEUq3aft jVnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683892141; x=1686484141; 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=Z/0fKyKc/tyHGAvUMiEABkHz81kuw978UPg4O7+vJhA=; b=UvMg3ky6ZW0Amq9IjWSjCn+ptgl1KvPnP8RFhiFopQA8YanHamhOvsd8DLgv/Si7CY touq+7Yuhzu9fVvqCDJKSPiTOnbbFARIBzHrHRreTPZECn+I5iVxwcU3LEudWnzIekSv 0bP/Hn2RcKjbvRgyd5F2yP5LHfd1MT9BjLzrzeXp3LTa9/tFK7xCzhIaGbbM1aOB8UxN /hB04YN9MyKj8RlG6gU4RuC+RZ5iCovwBGeFb47NF4VH7HE0120OqsKVfGpVSkbWURDX uEsr95kuG/+4Fc53qhwAUdSy7m2OJ158/Lj76jLxWXfazDYagynWCBV0cqjKxkVB+0L+ uDog== X-Gm-Message-State: AC+VfDxAwphQsyHHhEmzFOflLjTV19BsU5h9WU5xjpZ0pfS1p2A2/JVw uN6tT/C0u7cdXw8YSpvMisc= X-Google-Smtp-Source: ACHHUZ5JgB9f3Nd8vP8iiTl3sZD9yI0kXM7mfGA9s24IA2h/iXiRUzj4MlLZzg/NMSGJDjpY9b1TAw== X-Received: by 2002:a6b:e806:0:b0:76c:880e:417a with SMTP id f6-20020a6be806000000b0076c880e417amr2682166ioh.10.1683892141312; Fri, 12 May 2023 04:49:01 -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 r15-20020a6bd90f000000b0076ca45ebfc4sm330374ioc.14.2023.05.12.04.49.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 May 2023 04:49:01 -0700 (PDT) Message-ID: <9fc58fad-5d2f-e288-ced5-83fb5813e7af@gmail.com> Date: Fri, 12 May 2023 07:48:59 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Is the GNUC dialect anything that GCC does when given source code containing UB? (Was: 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> <87h6si9jn0.fsf@yahoo.com> From: Eli Schwartz X-Clacks-Overhead: GNU Terry Pratchett In-Reply-To: <87h6si9jn0.fsf@yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KAM_SHORT,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/12/23 1:57 AM, Po Lu wrote: > Eli Schwartz writes: >> 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. Instead of adding one flag to their Makefile, which is too much work, they will add *many* declarations of `extern int foo();` across many source files in the same project? Very interesting definition of burdensome work. You keep saying "just about what anyone will do", but I do not believe this is what anyone other than you will do. > 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 reading is faulty, and your beliefs about how software work are also faulty, if you believe that the issuance of a diagnostic is what constitutes adding new features to the language dialect called "GNU C". Please start a new thread, titled something like "the documentation is flawed, which should be fixed, because implicit function declarations are referenced but not to clearly". Argue there, that implicit function declarations should be documented on the "C Extensions" page. Until everyone is on the same page as you about whether these are GNUC extensions, this conversation will go nowhere. >> 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? "no one agrees with you" is a common idiom that states that a person (in this case Po Lu) holds an opinion that rest of the world (all persons not named Po Lu) do not hold. Since you cannot agree with yourself -- you are yourself -- I am forced to believe that you are trolling by accusing me of denying you personhood. >> importantly, GCC does not agree with your analysis. > > For some definition of GCC, which is apparently you. No, just the GCC manual. >> 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'. Irrelevant, I shall ignore this comment -- it is not listed on the "C Extensions" page. >> 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: The concept of a language extension is defined by the page that says "these are the extensions to the language". Please take your mendacious reading of the C standard and put it back where you got it from. > - 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. ... because the GNUC language dialect is not synonymous with either undefined, unspecified, or implementation defined behavior. Quoting random definitions of things that aren't "C Extensions" don't make them C Extensions. I also find it difficult to understand how adding a diagnostic telling you not to do something would be synonymous with "precisely defines" doing that thing. There's nothing precise about it? "Nothing gcc.info says will change that". What? Please tell me how this can be so. What precisely defines the behavior if not the manual? Defining something is to create a description of that thing. English language prose is the standard for creating descriptions. That's the documentation. What else are you looking at here? > GNU C documentation does not decide what is an extension and what is > not. I am framing this and putting it on my wall. > 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. Please submit a bug report to GCC requesting that this be added to a section titled "implementation-defined and locale-specific characteristics". Do not expect it to be added to a section titled "C Extensions to the language, which shall be known as the acceptable GNUC dialect". >> 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'? Why does C++ compile with `gcc` as long as it has the right heuristic file extension? Why is __GNUC__ defined when you specifically ask for -std=c89, which is not -std=gnu89? I assume because the compiler is kind and forgiving, and will often allow you to mix dialects even though you shouldn't, if it can be done safely and without conflicting other stds. But implicit-function-declarations cannot be done safely. ... This discussion is going nowhere until you accept that GNUC has a definition and that definition is separate from "what GCC does when given UB". -- Eli Schwartz