More C type errors by default for GCC 14

[David Brown]

On 14/05/2023 07:28, Po Lu via Gcc wrote:
> Eli Schwartz <eschwartz93@gmail.com> writes:
> 
>> Quoting my previous reply on the topic.
>>
>> Until everyone is on the same page as you about whether these are GNUC
>> extensions, this conversation will go nowhere.
>>
>> You are of the opinion that "GCC currently behaves a certain way when
>> compiling the code" means that the behavior is documented and specified
>> as a "C Extension" for the GNUC language dialect.
> 
> Yes, by the definition of ``extension'' used by everyone except you.

I can't speak for "everyone", and I don't think you can either.  But I 
believe I am safe in saying that everyone who has expressed an opinion 
in this thread, agrees with Eli's definition - GCC C extensions are what 
the GCC C manual documents as extensions.

The behaviour of a particular compiler does not define the extensions. 
At best, these are "undocumented features" - if you find them consistent 
enough and useful enough on a particular version of a particular 
compiler, then you may be willing to rely on them despite a lack of any 
kind of guarantees or documentation.

(You might note that there are several compilers, not just GCC, that 
implement many of the GNU C extensions.  I don't believe any of them 
makes any guarantees about your imagined undocumented extensions either.)

> 
>> Undefined and undocumented behavior is not a language extension. It is
>> undefined and undocumented behavior.
> 
> But when it becomes defined by the translator, in a precise way, it
> becomes an extension to the Standard.

No, it becomes an artefact of the particular implementation.  And if you 
have studied that implementation closely enough to see that it fulfils 
the specifications you want, not just its actual specifications, then 
feel free to keep that implementation and use it.  But you have 
absolutely no basis for expecting that any other implementation (such as 
future gcc versions) implement the same undocumented specifications.

> 
>> You may feel free to take an exact GCC release (source or binary),
>> analyze it, reverse-engineer it, or verify that it does what you want
>> it to do, and then trust that those undefined and undocumented
>> behaviors are ***benevolent***, but that doesn't cause it to be
>> defined and documented, and your trust will, if you are wise, depend
>> on you pinning an exact source code commit of the compiler. Do not
>> depend on bugfix releases of GCC to preserve your undocumented
>> semantics. They may or they may not, but if they don't, it's not a GCC
>> bug, because it is ***undocumented***.
> 
> GCC does not implement its documentation.  The documentation is supposed
> to describe (_not_ specify) how GCC behaves, and when the documentation
> is wrong or contains omissions, the documentation will have to be fixed.
> Not the compiler itself.
> 
> And it's not just GCC.  Almost all programs work this way.
> 

It is a sad fact that many programs /are/ written that way - rushed 
coding under a manager's whip until the code works well enough to pass 
some basic tests, then it is shipped to end users.  Documentation, if 
any, is written afterwards with barely a nod towards a specification.

The /correct/ way to write code is to specify first (as formally and 
thoroughly as appropriate for the project), and have everyone agree that 
the specification fulfils the requirements for the program and that it 
is feasible to implement in practice.  /Then/ start writing code.  If 
the specification is user readable, then it forms the basis for the user 
documentation - if not, then user documentation can be written before, 
during or after code development.

For a living and evolving project like GCC, this all works in lots of 
small steps and in practice changes to the code and changes to the 
documented specifications get committed together, to keep them 
synchronised.  But it is always logically a documented feature and code 
that implements that specification.  (The specification can be a bug 
report, not just the user documentation.)


Attempting to do what you describe - look at the behaviour of gcc in 
practice, document it and call it the specification - would be insane. 
I've already tried to explain on this thread how the logical consequence 
of such ideas is total stagnation of the gcc development.  Look at the 
bugzilla database for GCC - it is /huge/.  Every (valid) bug there is a 
case where GCC does not do what it was supposed to do - what it is 
/documented/ to do.  You would have the GCC folks spend their time 
updating the documentation to redefine these bugs as previously 
undocumented features, rather than fixing the bugs in the code, and 
requiring all future versions of gcc to maintain bug-for-bug 
compatibility with the older versions.

Or could it be that you think this only applies to the features that 
/you/, personally, want to keep?  Sod the rest of the world, as long as 
/you/ don't need to fix your code?


I've come across a fair number of C programmers with your attitude 
before.  Generally they don't realise the consequences of their desires, 
or how limiting they are.  They think they are fighting on behave of 
others in the same position, arguing that they should be able to 
continue to rely on undocumented and unwarranted behaviour that has 
worked before.  It sounds reasonable, until you look at what it actually 
implies - and until you consider all the other groups who also want to 
rely on /different/ selections of undocumented and unwarranted 
behaviour.  And then, of course, there are all those C programmers who 
try hard to stick to actual documented and warranted behaviour, and 
would like the best warnings and development aids to help them write 
good, correct code, and who then want the results to run as efficiently 
as possible.

The irony is that the people who want their compiler to behave as it 
always has (for their particular type of code, and their particular 
unwritten ideas of how to behave) usually complain loudest about GCC. 
And GCC is, of all the compilers I have used, the best at having 
/documented/ flags to give these people exactly what they are looking 
for.  For some, it is "-fwrapv", others 
"-fno-delete-null-pointer-checks", and others it is 
"-Wno-implicit-function-declaration".

David