On Sun, 14 May 2023, 06:28 Po Lu, wrote: > Eli Schwartz 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. > Wrong. I wouldn't bother replying to you again in this thread, but I feel that as a gcc maintainer I should confirm that Eli S. is right here; and nobody else I know agrees with your definition of extension as "every non-standard aspect of the compiler's behaviour, whether intentional or accidental". That's just silly. > > 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. > Some is in docbook XML, and some is in HTML (namely the release notes). > > 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. > No, Eli S. is quite right. > > 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 when the compiler is wrong and the documentation is correct, the compiler is fixed. > And it's not just GCC. Almost all programs work this way. >