On Fri, May 12, 2023 at 11:03 AM Florian Weimer <f...@deneb.enyo.de> wrote: > > * Joseph Myers: > > > 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. > > Obviously makes sense to me.
Agreed. But we could safely continue to accept static x = 42; or even auto x = 42; // meaning of 'auto' changes, meaning of the declaration does not We might make -Wimplicit-int an error by default only if the initializer has a type other than 'int'. > > 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). > > Just to recap, those are controlled by > -Wimplicit-function-declaration, -Wimplicit-int, -Wint-conversion, and > -Wincompatible-pointer-types, roughly in increasing order of > compatibility impact with old sources. What would the impact be of making -Wint-conversion an error by default only if the types are different sizes? Jason