Re: More C type errors by default for GCC 14

[Jason Merrill <jason@redhat.com>]

On Fri, May 12, 2023 at 9:20 AM Po Lu via Gcc <gcc@gcc.gnu.org> wrote:
> Yes, just these quotes from a former GCC maintainer:
>
>   In C, we cannot divide all user code into "right" and "wrong" in this
>   kind of simple way, and certainly not based on the ISO standard.  That
>   standard is just the decisions of a certain committee (which I was a
>   member of) about what cases conforming compilers should commit to
>   support.  We must not let ourselves start thinking that C code is
>   "wrong", just because it is not conforming ISO C code.
>
>   C programs use many cases that are not conforming, but do work.  This
>   will be true for as long as C is used, because changing it would
>   require major changes in the C language.
>
>   From time to time, there is a real *need* to make some of these cases
>   stop working, for the sake of some benefit that users want.  When this
>   happens, we should do it; the user community will accept it, because
>   they will see that it is being done for their sake.  Some will
>   grumble, but the users who appreciate the benefits will convince them.
>
>   But when there is no *need* to break these cases, when we can keep
>   them working fairly easily, we should keep them working.  If we break
>   them unnecessarily, we invite the legitimate anger of the users.

Absolutely.  The debate is really over the degree of "need" and the
degree of "break".

The proposal argues that the need is to help developers using GCC
avoid a common class of wrong-code bugs that have gotten worse with
the rise of platforms with 64-bit pointers and 32-bit int, and even
more with the adoption of position-independent executables as a
security measure.

The "break" is asking affected legacy code to adjust build flags, if
they don't want to adjust their code.

Note that some such legacy code does in fact need to be fixed to work
properly on modern systems, e.g.
https://developers.redhat.com/blog/2019/04/22/implicit-function-declarations-flexs-use-of-reallocarray

Certainly there are people in both camps with valid perspectives, as
Florian pointed out early in his initial email.  Previously, we've
leaned toward the second camp for these particular issues.  But the
problem above strengthens the case of the first camp. And the
dwindling amount of affected code weakens the case of the second camp.
And so the proposal suggests that we change the default behavior.

As a compromise, it should be possible to error by default only in
cases where the implicit int (including as a return value) is either
the source or target of a non-value-preserving conversion, as those
are very likely to be bugs.  That seems desirable for both camps.

A simpler change to catch this particular bug would be to make
-Wint-conversion an error by default iff the sizes differ.

(Incidentally, for the first camp, it seems desirable to have a flag
to upgrade all currently enabled pedwarns to errors without also
enabling pedwarns that depend on -pedantic/-Wpedantic;
-pedantic-errors does both; -Werror=pedantic makes only the latter set
errors, which seems unlikely to be useful to anyone.)

Jason