From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fencepost.gnu.org (fencepost.gnu.org [IPv6:2001:470:142:3::e]) by sourceware.org (Postfix) with ESMTPS id 66F63385783F for ; Wed, 10 May 2023 18:17:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 66F63385783F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=nV1lPqn6vUt4NA5k6YkLhGDsbAXD3uHvpAbbgIqv66U=; b=ShuVOO8j/8Fc a0Nnb1L8nh/EcuGM+tGtm8sfox8QGUA1vXw3U+816of/PffA45iAyjSCRU70xo0dMNXmOQWCauhCu noPexwSnzcD88xur73yNyTuVC4HJrQ/16hvDq8tell0dpTrvU23w3tJzCdVbCwuimwBub1ssI0sX8 bjBgxPn35bwgAJi3KTtorxD8WGU2ioYFLNzADfwI5tNz1kuVBDnE9YRbrGxlCGtHrTIk2M4SWmQBP 2sjt9p6gMy+r9qdHLRL+l1GZT41ciYgNXqamrE91u/tLGaynREP51ZbJaZyLhFnSTT5n5e55/6Qys aolm4AECoBSr4nC/51S6XA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pwoNY-0000um-1g; Wed, 10 May 2023 14:17:33 -0400 Date: Wed, 10 May 2023 21:18:37 +0300 Message-Id: <83cz386oea.fsf@gnu.org> From: Eli Zaretskii To: Joseph Myers Cc: jakub@redhat.com, gabravier@gmail.com, jwakely.gcc@gmail.com, fweimer@redhat.com, gcc@gcc.gnu.org, arsen@aarsen.me In-Reply-To: (message from Joseph Myers on Wed, 10 May 2023 17:08:18 +0000) Subject: Re: More C type errors by default for GCC 14 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> X-Spam-Status: No, score=2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Date: Wed, 10 May 2023 17:08:18 +0000 > From: Joseph Myers > CC: Jakub Jelinek , , > , , , > > > 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. So in this case, I'm okay with GCC changing the default behavior at some point, such that the above is interpreted as C2x mandates, which will then break some old programs. This is another example of a "good reason" for changing behavior in backward-incompatible ways. But please note that emitting an error is not required, at least in my book. I assume GCC emits a warning about this already, and that should be enough, until such time as you decide to adopt the C2x interpretation of that by default -- without going through the intermediate stage of erroring out by default. > 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. FWIW, I don't see a reason to give an error. > 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. IMO and IME, anything is better than errors. I presume everyone on this list is familiar with the frustrating experience of having a large program suddenly fail to build with some strange-looking error message, which launches you down the rabbit hole of trying to understand what happened and why. And if that happens as part of running the configure script (as I understand is one of the potential victims of that), that is even scarier, because most people don't read the configure script and don't always understand what is going on there and why; it is also not very easy to debug. So I urge the GCC developers to try to avoid errors as much as possible, as long as GCC is capable to produce code with some widely adopted semantics, and break backward compatibility only if otherwise GCC will be unable to implement newer features. (And to be pedantic, I don't consider new warnings to be new features in this context.)