From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) by sourceware.org (Postfix) with ESMTPS id ABDE43858C2D for ; Sun, 14 May 2023 05:56:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ABDE43858C2D 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-x12c.google.com with SMTP id e9e14a558f8ab-3361b08a564so21675955ab.3 for ; Sat, 13 May 2023 22:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684043787; x=1686635787; 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=8/Dc0qKs9sZ3VfnSwlCTmVQh6rkNKhxrUQYCiUPY4g8=; b=OViHMKp7DI99vhWV65c5x5Av6gVDOvDj71oBAlD8eC3K+uurKVo6euB6DJsrq1153s TSbV67ZdtLENU/0YyT+/MEEJXX5DKTSNm8sh5sfT3r2vPEVxx6U0Y4HmpV0lH7EReFtm 19VKAQTr5SuF1v/1JJZUW7QE92yF6AIVfLm8w0OFRrx2xryxLkCF/OE0QLcPccG2ilmJ N+N2L4LyaCtQF21giDOgCrhumFxOu/b+3V/FRSDbBt25OXaJ5tkAI7KCukVuKISqsg3R 9dfSms9Czu8aoGRBc58B3ASIbT5TO4H0/H3SGo/Y7jFmHyaO17Q0wUgmaOReS8wiFp2d 6R/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684043787; x=1686635787; 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=8/Dc0qKs9sZ3VfnSwlCTmVQh6rkNKhxrUQYCiUPY4g8=; b=MR9p3ctGf1O1K3TG87P69KT5FRZ5uMlFSxQV1XmZfXfTO42xz6M6OZk/HGG86Cm9t2 RSpfxoflgkC6OxYa8omi/mLyy83/ws5SUA5vRk4/EaBhhCnCli9SmzSedoDhPnPsJQJ4 ZWV+3r2TS7D6/FsGs7EVw+h03ZbYK4knQ49yg3YB+WQNawKu5wpR/SSsQbYN4/066T5O O72wREa6OAqVA/Ivsexs3rNazAhWVJhOJXbx2TPZawPgdD8ln8kvO1kesZB/KROh72JC ueB0STvgncWc4GKPg30PpQw0KP2hz5ED5X1oYY+5uFZW7DDGg7N+HfhZ8wzhLnhBI2Ow aPBA== X-Gm-Message-State: AC+VfDxyyWHhbeIWyo/NCuzxuq6SJxOMtwrtCZtIvJEt68ISY3xj9ebd nO3lp+dbyouZ+NAiNuhZTwI= X-Google-Smtp-Source: ACHHUZ71YAvaHljRhzwXdnaUIDJDM2q5afuq0PYxyRAEDux2896wysAmO9p+3PAp60Su4d0qBVad7A== X-Received: by 2002:a92:d482:0:b0:337:3577:2862 with SMTP id p2-20020a92d482000000b0033735772862mr3808541ilg.16.1684043786729; Sat, 13 May 2023 22:56:26 -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 v13-20020a92c6cd000000b003358e4653c6sm3452346ilm.36.2023.05.13.22.56.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 May 2023 22:56:26 -0700 (PDT) Message-ID: <4b378f94-340d-de5b-c523-e7a5a603c11b@gmail.com> Date: Sun, 14 May 2023 01:56:24 -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: Gabriel Ravier , Jonathan Wakely , Eli Zaretskii , "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> <83bkiq3umf.fsf@gnu.org> <87sfc18z66.fsf@yahoo.com> <1cb56b16-1ee0-e233-30f2-464c30d19fd4@gmail.com> <87y1lt6ouy.fsf@yahoo.com> <4ea0b0de-c1f6-0708-eb57-69b4b0e458fc@gmail.com> <87353z7a7o.fsf@yahoo.com> From: Eli Schwartz X-Clacks-Overhead: GNU Terry Pratchett In-Reply-To: <87353z7a7o.fsf@yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 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/14/23 1:28 AM, Po Lu wrote: >> GCC has formal documentation. It is written in HTML. If it is lacking, >> then the only valid move is to improve the HTML documentation and then >> abide by it. In the absence of documentation, all behavior is, well, >> "undocumented", which ***definitely*** means it isn't a formal GNUC >> language dialect extension. > > GCC documentation is written in HTML? That's news to me. I always > thought it was written in Texinfo. Does this mean you've conceded the point, and no longer think it is written in C++? :) >> You can stop arguing your opinions based on what running gcc or g++ >> produces in the form of machine code. What gcc or g++ produces in the >> form of machine code is not guaranteed even across bugfix releases -- >> your only guarantee is that if it is documented in the ISO standards >> documents or in the GCC html manual, the produced machine code shall be >> in accordance with what the documentation says it shall do. > > Generated machine code, really? Not long-standing and observable > behavior of the translator itself, as has been re-iterated over and over > again? You are correct in reading my sentence, that is indeed what I said. Aside: you have reiterated "the behavior of the translator itself" over and over again, but it hasn't been generally reiterated, or even iterated. >> Undefined and undocumented behavior is not a language extension. It is >> undefined and undocumented behavior. > > But when it becomes defined by the translator, in a precise way, it > becomes an extension to the Standard. Repeating this statement won't make it true. >> You may feel free to take an exact GCC release (source or binary), >> analyze it, reverse-engineer it, or verify that it does what you want >> it to do, and then trust that those undefined and undocumented >> behaviors are ***benevolent***, but that doesn't cause it to be >> defined and documented, and your trust will, if you are wise, depend >> on you pinning an exact source code commit of the compiler. Do not >> depend on bugfix releases of GCC to preserve your undocumented >> semantics. They may or they may not, but if they don't, it's not a GCC >> bug, because it is ***undocumented***. > > GCC does not implement its documentation. The documentation is supposed > to describe (_not_ specify) how GCC behaves, and when the documentation > is wrong or contains omissions, the documentation will have to be fixed. > Not the compiler itself. > > And it's not just GCC. Almost all programs work this way. In fact, lots and lots and lots of programs do indeed operate such that the documentation specifies how the program shall behave, and when the program fails to behave in the manner in which it is documented to behave, the program shall be fixed. We call these failures to behave according to the documentation, Bugs. Occasionally it is also called specification-driven development. ... In cases where the documentation says nothing at all, for good or ill, the behavior of the program is undefined -- users cannot rely on it, for they cannot know what is intended and what is not intended -- in this case, the intended behavior must be defined, documented, and implemented, and "the program currently does X" gets one vote out of many and is not guaranteed to get its way. Very often in such cases the best user-serving thing to do is to define the behavior as "shall not be used, and for legacy reasons if you use it it will continue to do X but raise a warning telling you that you are required to stop depending on it" and possibly even "it may disappear in semver version YYY". Sound familiar? A bit like GCC triggering a warning, telling you that what you're doing is bad and should not be relied on? But GCC isn't dropping support for it in semver version anything, just guarding its use behind an opt-in flag. -- Eli Schwartz