Re: More C type errors by default for GCC 14

[Jakub Jelinek <jakub@redhat.com>]

On Wed, May 10, 2023 at 02:30:07PM +0300, Eli Zaretskii wrote:
> > From: Jonathan Wakely <jwakely.gcc@gmail.com>
> > Date: Wed, 10 May 2023 09:04:12 +0100
> > Cc: Florian Weimer <fweimer@redhat.com>, "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>, 
> > 	Jakub Jelinek <jakub@redhat.com>, Arsen Arsenović <arsen@aarsen.me>
> > 
> > void foo(int);
> > void bar() { foo("42"); }
> > 
> > Why should this compile?
> 
> Because GCC is capable of compiling it.

That is not a good argument.  GCC is capable of compiling any code in all
the reported accepts-invalid bugs on which it doesn't ICE.  That doesn't
mean those bugs shouldn't be fixed.

C99 for the above says:
6.5.2.2/7
"If the expression that denotes the called function has a type that does include a prototype,
the arguments are implicitly converted, as if by assignment, to the types of the
corresponding parameters, taking the type of each parameter to be the unqualified version
of its declared type."
and
"One of the following shall hold:
— the left operand has qualified or unqualified arithmetic type and the right has
arithmetic type;
— the left operand has a qualified or unqualified version of a structure or union type
compatible with the type of the right;
— both operands are pointers to qualified or unqualified versions of compatible types,
and the type pointed to by the left has all the qualifiers of the type pointed to by the
right;
— one operand is a pointer to an object or incomplete type and the other is a pointer to a
qualified or unqualified version of void, and the type pointed to by the left has all
the qualifiers of the type pointed to by the right;
— the left operand is a pointer and the right is a null pointer constant; or
— the left operand has type _Bool and the right is a pointer."
For the above case, none of that holds and it isn't something desirable to
be supported as GNU extension, because while it could happen to work as the
user wanted after cast back to pointer in foo on ilp32 architectures, it
doesn't make any sense on lp64 or llp64 architectures.

Note, this isn't valid even in C89 and is already rejected with
-pedantic-errors for years.
The proposal is essentially to stop accepting this as a GNU extension
which was added for K&R compatibility I assume and do that only for C99 and
later.

> It compiles today with a warning, so that whoever is interested to fix
> the code, can do that already.  The issue at hand is not whether to
> flag the code as highly suspicious, the issue at hand is whether
> upgrade the warning to errors.  So let's talk about the issue at hand,
> not about something else, okay?

We do such changes several times a year, where we reject something that has
been previously accepted in older standards, admittedly mostly in C++.
Yes, it is done far less in C, but still, as the above is invalid already in
C89, users had over 3 decades to fix their code, and in many cases they
didn't and without this move they will never bother.
A lot of such broken code has been even written in those 3 decades, doesn't
predate it, but because the compiler just warned on it, it still appeared in
the code bases.  If we wait with this change another 2 decades, nothing will
change and we'll have the same problem then.

	Jakub