From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by sourceware.org (Postfix) with ESMTPS id 6C8F63858D28 for ; Sun, 14 May 2023 05:08:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6C8F63858D28 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-xd34.google.com with SMTP id ca18e2360f4ac-76c5a225388so150729439f.1 for ; Sat, 13 May 2023 22:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684040924; x=1686632924; 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=IATLGFC2UkR3D9Kn0kHDrwQvLKmWXxL0aqcgEU1Y82c=; b=e3nwvz6ux07kEA8eR3jR6hUiYhkeok9eIvCp+v7w4hiBX4hfp4f2NbPEhIHpqmP9D4 q6AOchkXXmS6Y2fupTu31OG+2t6mDRvhWZU//QqmpgiMFjC6DV+9psT5lqJ8/6bo6MTK hvGwi3ofkMv759PaxDY0GiABoVewgJBfKWS17nBd4HpTXn2fgoJqXIlxF62USEom3pTf DcVD2cDrs7TxIghxlY74kEq7tnnUBOlSXd8+iQC3qt1bnbulPWl2z1k8qKsKdKr3u7zZ Og+HpzGzgal5pkeZe02FWx2giScSounDe95eZViehha6nnpm7KdIYEmwqmbMG8jDAf2E vvww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684040924; x=1686632924; 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=IATLGFC2UkR3D9Kn0kHDrwQvLKmWXxL0aqcgEU1Y82c=; b=ggGfPNx4jnUKjc44fQo2Lr6RXglez5Ecc/hhP0a3pniAmzUrulwoZPkZPDtXc0b9pC nU+2cyfrI8vPRhpD6COx3ON/NdkGM+XVvaLtOct1/+chA/zTlh+VOF3KvO+agyTSXZnC b2ZDXM0x5EkrfyVxSFGMjWJnd7aIT564ZS2Fd6j7zferAzTHxb8MIaG7YegwOpOMBYSM yEEV5Mga5+kulQzfWXAWzC9hey8SLKvK6zjPhgi1luICD8nJWnajbpY7kzSRzrQkqM6V aHlnDub/BDgmduv14hsvf4Juec2FaqXmFJJOrtysa7K04CSJ6uf9/+6l1HYw/YENz8Pj JA/A== X-Gm-Message-State: AC+VfDzvbsKqXL9sEyQ+fUo0rT3bPBvzIRVG9E/9fDWFeOFTusU0bUCA qyFmb+wf6PAjlZqTUmz9pDY= X-Google-Smtp-Source: ACHHUZ7mDwPPzfbbE9FFzQC30ebPlv3MIVEjr10xKNL4xx2ErktmqTZpnSWM6qqVJObrynNKsdGfQg== X-Received: by 2002:a92:501:0:b0:32b:49d8:299a with SMTP id q1-20020a920501000000b0032b49d8299amr18629313ile.17.1684040924483; Sat, 13 May 2023 22:08:44 -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 n15-20020a92d9cf000000b00335adc982e1sm3087740ilq.15.2023.05.13.22.08.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 May 2023 22:08:44 -0700 (PDT) Message-ID: <4ea0b0de-c1f6-0708-eb57-69b4b0e458fc@gmail.com> Date: Sun, 14 May 2023 01:08:42 -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 , Gabriel Ravier Cc: 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> From: Eli Schwartz X-Clacks-Overhead: GNU Terry Pratchett In-Reply-To: <87y1lt6ouy.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/12/23 8:45 PM, Po Lu wrote: > Gabriel Ravier writes: > >> ...You're joking, right ? You can't possibly be seriously arguing >> this, you have to be kidding... right ? > > No, I'm not. The meaning of a variable declaration with only a storage > class specifier is extremely clear: the type of the variable is `int'. > There's absolutely nothing ambiguous about it whatsoever: Quoting my previous reply on the topic. Until everyone is on the same page as you about whether these are GNUC extensions, this conversation will go nowhere. You are of the opinion that "GCC currently behaves a certain way when compiling the code" means that the behavior is documented and specified as a "C Extension" for the GNUC language dialect. You've provided some excuses like "C++ is a valid language for writing documentation in, and the HTML docs are lacking", but your arguments are not convincing. 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. 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. Undefined and undocumented behavior is not a language extension. It is undefined and undocumented behavior. 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***. ... So in answer to your question, the meaning of such a variable declaration is very much unclear -- C specifies one thing, GNUC doesn't specify *anything*, and actually executing the gcc compiler frontend tool will do... something. -- Eli Schwartz