Eli Schwartz <eschwart...@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.

> You've provided some excuses like "C++ is a valid language for writing
> documentation in, and the HTML docs are lacking", but your arguments are
> not convincing.
>
> 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.

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

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

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

Reply via email to