On Sat, 13 Jan 2018, Edward Diener via Boost wrote:
So a compiler is allowed to implement an extension to the standard which is non-compliant with the standard,
"non-compliant" is your judgement.
"Non-compliant" simply means that the compiler does not follow the C++ standard. What is judgmental about that ?
You are the one claiming it does not follow the standard, while it seems that it does follow at least the letter.
and then claim compliance to the standard by outputting a warning message instead ?
That's always been all the standards require. Picking a random sentence from the C++ standard: "if [...], a conforming implementation shall issue at least one diagnostic message". Seems pretty clear to me that warnings satisfy this requirement. And from discussions in the C++ committee, it is definitely interpreted that way.
Please quote an actual place rather than a random sentence.
[intro.compliance] "If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this document as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message." [defns.diagnostic] "diagnostic message message belonging to an implementation-defined subset of the implementation’s output messages" But I can't find any text forbidding the implementation to produce some binary object.
In that case what hope is there for the programmer to write C/C++ standard compliant code using such a compiler,
Note that this is not a priority for compiler vendors. Accepting legacy programs comes before rejecting invalid ones.
If the compiler is giving you a warning, read it? How is prefixing the message with "error:" clearer than with "warning:"?
An error stops the compilation, a warning does not unless you tell the compiler to treat warnings as errors. Good luck using the typical compiler if you do the latter.
Are you saying warnings are useless?
I do not care if it is Podunk C++. The principal that a compiler says it is standard conforming because it issues a warning rather than an error when it does not conform to the standard is what bothers me. If such behavior is actually part of the C or C++ standard then there is never any point at reporting bugs to any C++ implementation because their answer to any valid bug can be "we issue a warning but we are not going to bother to fix the bug because the warning makes us compliant".
You are over-generalizing. Most interesting bugs are about valid code that gets rejected, or accepted but for which wrong code is generated (or valid but slow code is generated). Then you can argue about helpful diagnostics that the compiler can provide to let developers know about potential issues, but aggressively claiming non-conformance may not be the most efficient way to present your argument. They already know about this since they have a warning, they probably already weighed the pros of accepting some customer's old code base vs more strongly telling users about an issue in their code, and consider the result a feature. Some chances of getting a change could be: - this was done a long time ago, maybe the old code is not relevant anymore - you demonstrate how the warning was ignored and this caused a bug for some important customer - ask for a better split between strict modes and compatibility modes (maybe a -pedantic-errors -like flag that turns all relevant warnings into errors)
I don't care what the bug actually is in this case, it's the attitude of the compiler implementor that irks me.
Try to see it from the other side. They would probably love to make it an error, but they have paying customers with legacy code (and I suspect this compiler in particular is used on legacy code more often than new code) and needed to find some compromise to make them happy, so they made it a warning (still conforming). Then come entitled non-paying users who tell them they absolutely must make it an error... What would you do in their place? Maxim's response was very polite and pedagogical, honestly explaining why this was unlikely to change. And along the years, I've read similar responses from all major compiler teams. -- Marc Glisse