Re: More C type errors by default for GCC 14

["Arsen Arsenović" <arsen@aarsen.me>]

[-- Attachment #1: Type: text/plain, Size: 3304 bytes --]


Eli Zaretskii <eliz@gnu.org> writes:

> It is not GCC's business to force developers of packages to get their
> act together.

Why not?  Compilers are diagnostic tools besides just machines that
guess what machine code you mean.

> It is the business of those package developers themselves.  GCC should
> give those developers effective and convenient means of detecting any
> unsafe and dubious code and of correcting it as they see fit.  Which
> GCC already does by emitting warnings.

There's a difference between dubious and unsafe code and code that is
unambiguously wrong, but was chosen to be accepted many years ago.

> GCC should only error out if it is completely unable to produce valid
> code, which is not the case here, since it has been producing valid
> code for ages.

Producing call code with wrong prototypes is not within my definition of
producing valid code.

> It is a disservice to GCC users if a program that compiled yesterday
> and worked perfectly well suddenly cannot be built because GCC was
> upgraded, perhaps due to completely unrelated reasons.

Please see the various porting-to pages.  Compilers stop being able to
produce code with older versions of programs because of them being a
lil' too lax and the programs accidentally relying on that every year.
There's nothing wrong there.

If compilers stopped being lax, such things wouldn't happen simply
because programs couldn't accidentally rely on it, so we'd get the ideal
world without breakages.  We don't get that by pretending code is fine
when it is not, and letting developers write that code.

Now, of course, this instance is different to porting-to pages, because
we aren't talking about code accidentally relying on a transitive
include or an edge case or somesuch, we're talking about the compiler
going out of its way to produce wrong code and whispering into the wind
about doing it.

> It would be a grave mistake on the part of GCC to decide that part of
> its mission is to teach package developers how to write their code and
> when and how to modify it.

It would be a grave mistake on the part of GCC to decide that part of
its mission is to pretend code is fine when it is unambiguously broken,
and then not tell people about it very loudly.

I don't think we should send out the message of "GCC: the compiler for
your untouchable legacy code, not for writing new code, or upgrading
existing code".

Providing compatibility here is a trivial job, we don't need to make
each developer suffer with tweaking compiler flags to get the compiler
to diagnose blatantly wrong code as errors, or more likely, not do it at
all because they don't know about this problem.

We could, of course, alter documentation to tell people that running GCC
in strict mode requires some concoction of flags, or we could alter it
so that it says that running GCC in a lax mode requires *one* flag, for
the exceptional case where code can't be easily fixed, and it's more
useful to pretend it's fine and emit broken calls.

We could even provide a 'laxgcc' or such driver that covers this
exceptional case OOTB (though I'm unconvinced that does anything that
setting CC='gcc -fpermissive' doesn't cover).

Have a lovely day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]