Re: More C type errors by default for GCC 14

[Joseph Myers <joseph@codesourcery.com>]

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