Re: More C type errors by default for GCC 14

[Eli Zaretskii <eliz@gnu.org>]

> From: Arsen Arsenović <arsen@aarsen.me>
> Cc: dje.gcc@gmail.com, jakub@redhat.com, jwakely.gcc@gmail.com, gcc@gcc.gnu.org
> Date: Wed, 10 May 2023 10:36:23 +0200
> 
> 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.

Diagnostics does not mean error.  A warning is also diagnostics.

> > 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.

Is GCC indeed capable of reliably distinguishing between these two?

And that code is not unambiguously wrong, since it is valid under old
standards, and thus can be compiled, and did compile, into a working
program.

> > 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.

I don't think I follow.  If the produced machine code is valid and
does what the programmer meant, why should we care about the
prototypes?

> > 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.

Once again, it is not GCC's business to clean up the packages which
use GCC as the compiler.  GCC is a tool, and should allow any
legitimate use of it that could be useful to someone.  Warning about
dubious usage is perfectly fine, as it helps those who do that
unintentionally or due to ignorance.  But completely failing an
operation that could have produce valid code is too radical.

We all want that the code of the packages be clean and according to
standards.  But using draconian measures towards that goal is dead
wrong, and is basically against the libertarian spirit that gave birth
to Free Software.  It is not an accident that GPL doesn't disallow
writing badly written or even crashing programs.

> > 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.

It is not broken, certainly not "unambiguously".  It did compile and
work in the very recent past.

> 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".

GCC sends the messages "don't write bad or dubious code" by emitting
warnings about such code.  There's no need to have a virtual gun
pointed to the heads of package developers to make that message so
much stronger, because doing that shifts the balance from merely being
a good and friendly tool towards second-guessing all of the GCC users
and knowing better then they do what they want.