From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id BB9AA3857017 for ; Wed, 10 May 2023 17:08:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BB9AA3857017 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.99,265,1677571200"; d="scan'208";a="4859670" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 10 May 2023 09:08:23 -0800 IronPort-SDR: ACA4h1QD4JzQ5QYqsny0uWZJ47YzN13H4L2BXCHab/VMIcX7dnpnyvaySZQhNTp/AIpxvin1Kw DK4sWXf9mOiHywq9uNYuDk1c5wYeZTIYyYRopX8WisRXGlDjWxQ2AQZo61pophD252OpIxgaaH yQIe7aCQbn5w3id5qvp+E9ZejYcnpIY72f5cd2Lm14elGy4BfByfDBKIVegNRQAZFOVXad9ocS GM/4AulC+JwFl3nvV0MNJfTmHU/yAIKnd+lYMUOodgAcFR8eTktX20h7WwH74WaRTAif8mghXJ s4c= Date: Wed, 10 May 2023 17:08:18 +0000 From: Joseph Myers To: Eli Zaretskii CC: Jakub Jelinek , , , , , Subject: Re: More C type errors by default for GCC 14 In-Reply-To: <83mt2c6tch.fsf@gnu.org> Message-ID: References: <87y1lx1avj.fsf@oldenburg.str.redhat.com> <83ednoapb6.fsf@gnu.org> <831qjoa0g0.fsf@gnu.org> <83o7ms8is7.fsf@gnu.org> <2ffbf210-1b58-737b-888c-4f84c5cc5e0f@gmail.com> <837ctg8e98.fsf@gnu.org> <83wn1g6w67.fsf@gnu.org> <83mt2c6tch.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3106.6 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_NUMSUBJECT,SPF_HELO_PASS,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: On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote: > 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. At block scope, auto x = 1.5; declares x to have type double in C2x (C++-style auto), but type int in C89 (and is invalid for versions in between). In this case, there is an incompatible semantic change between implicit int and C++-style auto. Giving an error before we make -std=gnu2x the default seems like a particularly good idea, to further alert anyone who has been ignoring the warnings about implicit int that semantics will change incompatibly. In cases where the standard requires a diagnostic, some are errors, some are pedwarns-by-default or unconditional pedwarns, some are pedwarns-if-pedantic - the choice depending on how suspicious the construct in question is and whether it corresponds to a meaningful extension (this is not making an automatic choice for every such situation in the standard, it's a case-by-case judgement by maintainers). By now, the cases discussed in this thread are sufficiently suspicious - sufficiently likely to result in unintended execution at runtime (not, of course, reliably detected because programs with such dodgy code are very unlikely to have thorough automated tests covering all their code) - that is it in the interests of users for them to be errors by default (for C99 and later modes, in the cases that were valid in C89). It might also make sense to review other pedwarns-by-default and unconditional pedwarns to consider if any of those should be errors by default, though I suspect most of those are less significant. Enabling some of -Wall by default (as warnings, not errors) might well also be beneficial to users, though case would be needed to exclude those warnings that involve stylistic choices (e.g. -Wparentheses) or have false positives that are hard to fix - not all of -Wall is for code that is objectively suspicious independent of the chosen coding style. -- Joseph S. Myers joseph@codesourcery.com