Re: More C type errors by default for GCC 14

[Po Lu <luangruo@yahoo.com>]

Arsen Arsenović <arsen@aarsen.me> writes:

> Any development style making documentation a source of truth matches
> this principle.  This does not refer to ISO specifications specifically,
> though, normally, unless the standard disagrees with reality, as
> implicit-... did many years ago, ISO decisions are taken seriously.

We're not talking about the C Standard here.  Eli S. is claiming that
gcc.info is the source of truth for the behavior of GCC, and whenever
some behavior of GCC is not documented (or contradicts the
documentation), GCC should be fixed to behave as its documentation
specifies.

> It is, after this proposal is accepted, still up to the user to decide.
> The only difference is that the default would be friendlier to new code
> and users and most code that exists today, rather than to very old code
> and incorrect code.

That's not correct.  It would be as friendly to new code as it is now --
but old (and very likely still correct) code would be put at a
disadvantage.

> Additionally, there isn't enough information to compile.  The compiler
> makes up new information to fill in the gaps.

According to a specific formula that all C programmers (at least, those
who write such code) know.

> If that definition accepted, most error recovery should be turned into
> valid code paths that participate as GNU extensions, for instance,
> there's no reason that:
>
>    int f (int x) { x += 10 return x + 123 }
>
> shouldn't compile, as the compiler knows where to insert semicolons to
> make it (probably) work.  I'd say that extension is more acceptable than
> the ones being proposed into turning into errors by default, since it
> isn't very ambiguous, unlike an implicit function declaration or such.

Unfortunately, this has never worked in any C compiler, and is very
ambiguous.  Implicit int and function declarations have been included in
every ANSI and K&R C compiler, and then some more after that, so what
the compiler should do is very precisely specified and known.

> It has been 25 years since the addition of -fpermissive to G++.  I'm
> optimistic.

But -fpermissive is considered ``useful'' by the many loud people who
find it necessary to compile C as C++.