> Date: Wed, 10 May 2023 17:08:18 +0000 > From: Joseph Myers <jos...@codesourcery.com> > CC: Jakub Jelinek <ja...@redhat.com>, <gabrav...@gmail.com>, > <jwakely....@gmail.com>, <fwei...@redhat.com>, <gcc@gcc.gnu.org>, > <ar...@aarsen.me> > > 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.)
