Re: More C type errors by default for GCC 14

[Eli Schwartz <eschwartz93@gmail.com>]

On 5/14/23 1:28 AM, Po Lu wrote:
>> GCC has formal documentation. It is written in HTML. If it is lacking,
>> then the only valid move is to improve the HTML documentation and then
>> abide by it. In the absence of documentation, all behavior is, well,
>> "undocumented", which ***definitely*** means it isn't a formal GNUC
>> language dialect extension.
> 
> GCC documentation is written in HTML? That's news to me.  I always
> thought it was written in Texinfo.


Does this mean you've conceded the point, and no longer think it is
written in C++?

:)


>> You can stop arguing your opinions based on what running gcc or g++
>> produces in the form of machine code. What gcc or g++ produces in the
>> form of machine code is not guaranteed even across bugfix releases --
>> your only guarantee is that if it is documented in the ISO standards
>> documents or in the GCC html manual, the produced machine code shall be
>> in accordance with what the documentation says it shall do.
> 
> Generated machine code, really?  Not long-standing and observable
> behavior of the translator itself, as has been re-iterated over and over
> again?


You are correct in reading my sentence, that is indeed what I said.

Aside: you have reiterated "the behavior of the translator itself" over
and over again, but it hasn't been generally reiterated, or even iterated.


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


Repeating this statement won't make it true.


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


In fact, lots and lots and lots of programs do indeed operate such that
the documentation specifies how the program shall behave, and when the
program fails to behave in the manner in which it is documented to
behave, the program shall be fixed.

We call these failures to behave according to the documentation,


Bugs.


Occasionally it is also called specification-driven development.

...

In cases where the documentation says nothing at all, for good or ill,
the behavior of the program is undefined -- users cannot rely on it, for
they cannot know what is intended and what is not intended -- in this
case, the intended behavior must be defined, documented, and
implemented, and "the program currently does X" gets one vote out of
many and is not guaranteed to get its way.

Very often in such cases the best user-serving thing to do is to define
the behavior as "shall not be used, and for legacy reasons if you use it
it will continue to do X but raise a warning telling you that you are
required to stop depending on it" and possibly even "it may disappear in
semver version YYY".

Sound familiar? A bit like GCC triggering a warning, telling you that
what you're doing is bad and should not be relied on?

But GCC isn't dropping support for it in semver version anything, just
guarding its use behind an opt-in flag.


-- 
Eli Schwartz