More C type errors by default for GCC 14

[Jason Merrill]

On Fri, May 12, 2023 at 11:03 AM Florian Weimer <fw@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