From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) by sourceware.org (Postfix) with ESMTPS id E46A6385841C for ; Sun, 14 May 2023 05:10:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E46A6385841C 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-xd32.google.com with SMTP id ca18e2360f4ac-76c626eb5d1so147427939f.0 for ; Sat, 13 May 2023 22:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684041005; x=1686633005; 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=e1MdRraEttHuKPOeiOxlYSU/ME4AUjbT0BTL09gjTAc=; b=aIaXOfLDNgWdKLOFarMudMWwL5ZN4fdGeJjEtXPC6+s60ZD/Q8SfdmKsineqyCljkD pymLce+5VR9nOnN/TwOOF39C2FohLho2rO4SzL7WfDNXBAeG5xgswOYtdizFg2SoTU6j CMqJT1AgQAkm9ApIajses2gMTxrvbZTOT6gpbyepvyn+EZOZibtkx5QMMQHGZDi8EjjM /iAyOkBvAqD1HnpxE6fjAB5ynSKuuC9Ks/amrcfLeEdxedPo9uniuFuikp/zYa+LlLTi FJ4Gt1ecEmjQ08qYhMo/ENrjS9m41NisrwfNYGFkFtrC45ZL/g7woRCIX3JJpmnn4w6m MoTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684041005; x=1686633005; 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=e1MdRraEttHuKPOeiOxlYSU/ME4AUjbT0BTL09gjTAc=; b=IgM8wPO/GrKCgGyRMkOfPM1qpm7RPpJGYrHqCEeLf9y7rip0c4u4jhf06PO0EQALS4 yLTDFdDTEqVgtvDCQEgtlMH/7CCxWwbmJS1YhULiic/gRdvApEoLTavBoW22pu4OKreQ CUil0PR38tNCbhTx1rYFCxiv3r8FMO0cOZ318kFpXUCI6nwAHWxEHHbL1OTt22Aq45Ig bj3Xck6elBPUopUwFqLEQfYotaediFV6DeLUW71ZxCc2qXo6oksh0Lma0t+LZxY0lHtN fW1yhDLZYcm0TmRAkZ31RonaYRUKN4AchePk/Es7Tt15IMWMGDApPQ1vbQgmA/+hmLFF KlLQ== X-Gm-Message-State: AC+VfDxvnP5yOVII1+0fsExBQA6u0ifCl4m3k0RkKGiWT8n3zEbbiixg L0F/Qju1btJNltHFs0B9v+Q= X-Google-Smtp-Source: ACHHUZ7tLFcl+J4054l2NiI2S9tdByUWQGlhDwplelvU1/6rhkChhDWT55gBig4FtP6BKj7ImDHyqA== X-Received: by 2002:a6b:f315:0:b0:76c:6b11:9186 with SMTP id m21-20020a6bf315000000b0076c6b119186mr9902002ioh.14.1684041005089; Sat, 13 May 2023 22:10:05 -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 10-20020a5d9c0a000000b0076c70f8c4d1sm2747885ioe.45.2023.05.13.22.10.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 May 2023 22:10:04 -0700 (PDT) Message-ID: <80defba2-5e0e-7e67-9d17-94e676716dd1@gmail.com> Date: Sun, 14 May 2023 01:10:03 -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 , Thomas Koenig 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> <83bkiq3umf.fsf@gnu.org> <87sfc18z66.fsf@yahoo.com> <1cb56b16-1ee0-e233-30f2-464c30d19fd4@gmail.com> <87y1lt6ouy.fsf@yahoo.com> <95ae59d6-097b-ebc2-06c5-b74a0544a2cc@netcologne.de> <87mt287p64.fsf@yahoo.com> From: Eli Schwartz X-Clacks-Overhead: GNU Terry Pratchett In-Reply-To: <87mt287p64.fsf@yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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/13/23 1:53 AM, Po Lu wrote: > There are no ``errors'' in Standard C (with the possible exception of > the #error preprocessing directive), only constraint and syntax rule > violations. Such violations are required to generate diagnostic > messages, after which the behavior of the translator ceases to be > defined by the Standard, but GNU C defines it to mean that the type is > int. GNU C does not define any such thing. It may happen to turn out that way, but that is not the same as defining its behavior. > Nor does GCC conform to the Standard by default: while it is okay for a > conforming implementation to translate programs relying on implicit int, > as there is no way doing so will alter the behavior of any strictly > conforming program, it is not okay to reserve keywords such as `asm'. > > The following strictly conforming program is thus not acceptable to GCC, > unless GCC is operating in standards-conformance mode: > > int > main (argc, argv) > int argc; > char **argv; > { > int asm; > return asm = 0; > } > > which shows that debating features based on the Standard is entirely > pointless, as the Standard allows implementations to provide almost > anything it prohibits. Sure, all I have to do is tell GCC to act like a C compiler. $ gcc -std=c2x /tmp/po.c -o /tmp/po; /tmp/po; echo $? /tmp/po.c: In function ‘main’: /tmp/po.c:2:3: warning: old-style function definition [-Wold-style-definition] 2 | main (argc, argv) | ^~~~ 0 But I don't understand what point you are trying to make, anyway. The Standard allows, but does not require, implementations to do many things if it so chooses. GNUC takes advantage of this when operating in GNUC mode, when also documenting GNUC features in the HTML docs. What does this have to do with implicit-int, which is a constraint violation? Where in the GNUC html documentation does it say that constraint violations applied to Type specifiers have been carved out as a GNUC extension? It's not a GNUC extension, you cannot assume it will work. It might work anyway, but that's a matter of luck. > So I ask you again: what is unclear about declarations which are > implicitly int, in a way that is likely to cause program errors? It is unclear why you are overly focused on implicit-int, to be honest. But your arguments in favor of implicit-int aren't very compelling either. -- Eli Schwartz