Re: More C type errors by default for GCC 14

[Eli Zaretskii <eliz@gnu.org>]

> From: David Brown <david.brown@hesbynett.no>
> Date: Thu, 11 May 2023 08:52:03 +0200
> 
> > But we are not talking about some random code that just happened to
> > slip through cracks as a side effect of the particular implementation.
> > We are talking about code that was perfectly valid, had well-defined
> > semantics, and produced a working program.  I don't care about the
> > former; I do care about the latter.
> 
> How would you know that the code had perfectly valid, well-defined 
> semantics?

The programmer who wants to keep that code will know (or at least
he/she should).

> I've had the dubious pleasure of trying to maintain and update code 
> where the previous developer had a total disregard for things like 
> function declaration - he really did dismiss compiler complaints about 
> implicit function declarations as "only a warning".  The program worked 
> as he expected, for the most part.  But that was despite many functions 
> being defined in one part of the code with one set of parameters (number 
> and type), and called elsewhere with a different set - sometimes more 
> than one selection of parameter types in the same C file.

In this situation, where you take responsibility of a program someone
else wrote, and consider its code to be badly or unsafely written, TRT
is to modify the program to use more modern techniques that you
understand and support.  Compiler warnings and your own knowledge of
valid C will guide you in this.

My problem is not with the situation you described, it's with a case
that the "previous" maintainer remains the current maintainer, and/or
for some reason rewriting the code is either impractical or not the
best alternative for other reasons.

> If a compiler is required to continue to compile every program that a 
> previous version compiled, where the developer was satisfied that the 
> program worked as expected, then the only way to guarantee that is to 
> stop changing and improving gcc.

There should be no such requirement.  If addition of new features or
support for the evolving standards mean GCC must break old UB-style
code, that is fully justified and understandable.  What is _not_
justified, IMO, is breaking old programs without any such technical
reasons, just because we think they are better off broken.  IOW, as
long as being able to compile those old programs in the same old way
doesn't get in the way of being able to compile valid programs, the
old code should remain unbroken.

> I agree that accepting fully correct programs written in K&R C would not 
> limit the future development of gcc.  But how many programs written in 
> K&R C, big enough and important enough to be relevant today, are fully 
> correct?  I'd be surprised if you needed more than one hand to count 
> them.

For the purpose of this discussion, the "how many" question is not
interesting.  If there is an incorrect K&R program, the results and
consequences of this incorrectness are on the maintainers of those
programs, not on the GCC team.  If some of those incorrect programs
break because of some valid development in GCC, so be it.

But the decision to make a warning to be an error is not dictated by
GCC development and its needs to compile valid programs, it is
dictated by other, largely non-technical considerations.  I'm saying
that these considerations are not reasons good enough for breaking
those old programs.

> Continuing to give developers what they expect, rather than what the 
> standards (and gcc extensions) guarantee, is always an issue for 
> backwards compatibility.  Each new version of gcc can, and sometimes 
> does, "break" old code - code that people relied on before, but was 
> actually incorrect.  This is unavoidable if gcc is to progress.

It is indeed unavoidable, and a fact of life.  All I'm saying is that
we as developers should try to minimize these breakages as much as
possible, without hampering new developments too much.

> That is why I suggested that a flag such as "-fold-code" that enables 
> long outdated syntaxes should also disable the kind of optimisations 
> that are most likely to cause issues with old code, and should enable 
> semantics chances to match likely assumptions in such code.  I don't 
> believe in the existence of correct K&R C code - but I /do/ believe in 
> the importance of some K&R C code despite its errors.

The problem, as you well know, is that when a large software package
fails to build, it is not immediately clear what is the reason for
that.  We here discuss a single such reason, but in reality no one
tells you that the build fails because the new version of GCC now
rejects code it accepted in the previous version.  The upgrade that
installed the new GCC will typically update dozens of other system
components, many of which could be the culprit.  Just understanding
that the reason is GCC and its rejection of certain constructs is a
job that can take hours full of frustration and hair-pulling.  This is
what I think we as developers need to avoid as much as possible.  Once
you understand the reason, fixing it with a compiler switch might be
relatively simple, at least in many cases, but the problem is the
effort it takes to realize that the option is all you need.  There are
no good ways of making that option discoverable enough to make this
process significantly easier.

> "Knowing what you are talking about" is not the same thing as being 
> correct.  But I think our key disagreements here are a matter of 
> opinion, not fact - "correct" is not an appropriate term for an opinion. 
>   We are looking at things from a different viewpoint, which will 
> naturally be coloured by our experiences.  So to be clear, I fully 
> understand your opinion and viewpoint here - I just don't think it 
> should be the philosophy for gcc going forward.
> 
> It is a good thing that we can express and exchange these opinions. 
> Ultimately, I suppose it is the gcc steering committee that will decide 
> (the length of this thread suggests it is too important for developers 
> alone).  I don't know about you, but I know that /I/ have absolutely no 
> say or vote in the process - I am not involved in gcc development. 

Neither am I.  I'm investing my scarce time in this discussion in the
hope to convince the GCC development team and the steering committee
to see the downside of the proposal to reject those old programs where
GCC can still compile them without affecting modern valid C programs.
I think a warning is good enough in those case.

> However, I think it is good that a wide variety of people are able to 
> give their thoughts, ideas and opinions, and I hope it helps the people 
> who will make the decisions in the end.

Agreed.