From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by sourceware.org (Postfix) with ESMTPS id 9E2AE3856261 for ; Wed, 10 May 2023 16:34:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9E2AE3856261 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-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-3f42ba32e24so15826355e9.3 for ; Wed, 10 May 2023 09:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683736446; x=1686328446; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=yFp8fQTmFM4hc626RyeTxE97cxEmJYtUDkxloNvnplM=; b=ojg/dEx8nTeFHAG/tFDSAI3MkID1/sDWFT6FyTZQVavAH0bvjIWp/BFPH4NusAsc1h bHt44nFa11aB2HW5SgQhoLBLTfgkvT76CIW5efZI+woWPDZGnn4xNZeVHMIJ5xgu2VfH nR8BTOgvFolLgDGo/dRsElzSmOWuW+zCq4EF0YyoBw+KOlYaNKCv95T67a5HZS+4WgKH 0mFpVb7950rNjIftIwkrArNjE4TyABG+Rz3qTnbWVR0orTPJ9sE+qhyJ1f7s5xC8I73m G+b5H45zgkFXx7reVYmMMEyvsw54tUqhr/uSp2YqzV1ShrYZdqGN/Fp8KIjYQehVjbWB j3Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683736446; x=1686328446; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yFp8fQTmFM4hc626RyeTxE97cxEmJYtUDkxloNvnplM=; b=FjBpypU5J+eMMgHGhfuz8wURRzjAPMSc+DXy06snLYyUiCiiQyAD3xpiPY6tDsdMd7 MUpUnvhTnr6x0axMq3pTdta2AEXW1j1paVDLusEoWH3la2u+CJ/Y6A9+L3wVQlSj6FvD 35WJRFNH7JO/acRdQWvKmeOT+pqf+QiKcSBu9v2z8MYah3v8a/TCKrs90+n1QL8j8pqJ uEZIQZnu4NeDnGLJXSoM/o1UqyF34joflyUntoakp9NhoweVi5PinGD8tWWqXK8Xin9f 2S2PJ/rsOXNXXZZioSIYIHpZSpgYhc8GMYxgSAVq+QFuc7O66YNqTyfZVd6Nhwal9NSW PpkQ== X-Gm-Message-State: AC+VfDy4VY+BCGqjGkFaGNJi18Wnq25udd91a6Qf0yVv9Zr3MKBTVO9L 3RsVmfP5EnmfugvbiWLXZr9faJXSW0U= X-Google-Smtp-Source: ACHHUZ7rpOEX32TB/xzzCu/FVuFWXBxYnogwFXnS826+04qrPRoHpOPx5S/wY9EUvag/KOi2PGMuxQ== X-Received: by 2002:a1c:7716:0:b0:3f4:5058:a037 with SMTP id t22-20020a1c7716000000b003f45058a037mr2665576wmi.37.1683736445542; Wed, 10 May 2023 09:34:05 -0700 (PDT) Received: from smtpclient.apple ([2a02:3038:200:a54c:4888:75bf:2246:bb16]) by smtp.gmail.com with ESMTPSA id l15-20020a7bc44f000000b003f4e3ed98ffsm1294696wmi.35.2023.05.10.09.34.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 May 2023 09:34:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: More C type errors by default for GCC 14 Date: Wed, 10 May 2023 18:33:53 +0200 Message-Id: References: <83mt2c6tch.fsf@gnu.org> Cc: Jakub Jelinek , gabravier@gmail.com, jwakely.gcc@gmail.com, fweimer@redhat.com, gcc@gcc.gnu.org, arsen@aarsen.me In-Reply-To: <83mt2c6tch.fsf@gnu.org> To: Eli Zaretskii X-Mailer: iPhone Mail (20E252) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Am 10.05.2023 um 18:31 schrieb Eli Zaretskii via Gcc : >=20 > =EF=BB=BF >>=20 >> Date: Wed, 10 May 2023 18:02:53 +0200 >> From: Jakub Jelinek >> Cc: gabravier@gmail.com, jwakely.gcc@gmail.com, fweimer@redhat.com, >> gcc@gcc.gnu.org, arsen@aarsen.me >>=20 >>> If some program is plainly invalid, not just because the criteria of >>> validity have shifted, then yes, such a program should be rejected. >>=20 >> Many of the accepts-invalid cases are when something used to be valid in s= ome >> older standard and is not valid in a newer standard, often even changes >> meaning completely in even newer standard. >> Examples include e.g. the auto keyword, which means something completely >> different in C++11 and later than what it meant in C++98, or say comma in= >> array reference in C++17 vs. C++20 vs. C++23 (a[1, 2] is the same as a[(1= , 2)] >> in C++17, got deprecated in C++20 and is ill-formed or changed meaning >> in C++23 (multi-dimensional array operator). >> Or any time something that wasn't a keyword in older standard version >> and is a keyword in a newer standard. >> alignas/alignof/nullptr/static_assert/thread_local in C++11 and C23, >> char16_t/char32_t/constexpr/decltype/noexcept in C++11, >> constinit/consteval in C++20, >> bool/false/true/typeof_unqual in C23. >>=20 >> int bool =3D 1; >> is completely valid C17 if one doesn't include header, >> or >> int static_assert =3D 2; >> valid C17 if one doesn't include >> etc. These used to compile and will no any longer wheen using -std=3Dc2x= or >> in a few years when -std=3Dgnu23 becomes the default will not compile by >> default, even when it used to be valid C17. >=20 > The examples you gave are the ones I could accept as "good reasons" > for breaking backward compatibility. That's because breaking that is > unavoidable if GCC wants to support the newer standard. >=20 > That is not the case we are discussing, AFAIU. Or at least no one has > yet explained why accepting those old K&R programs will adversely > affect the ability of GCC to compile C2x programs. But we are discussing to reject K&R programs only when C99 or later standard= s are applied (those are applied by default) Richard=20=