Re: [boost] Bug report rejected as conformant

Subject: Re: [boost] Bug report rejected as conformant
From: Marc Glisse (marc.glisse_at_[hidden])
Date: 2018-01-13 23:28:25

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