Re: [boost] Bug report rejected as conformant

Subject: Re: [boost] Bug report rejected as conformant
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-01-13 23:48:07

On 1/13/2018 6:28 PM, Marc Glisse via Boost wrote:
> 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.

No such thing of "it does follow at least the letter" in this case. The 
standard is completely clear on the particular issue, and has always 
been. Invoking a non-variadic macro with a number of arguments not 
matching the number of parameters is incorrect C or C++.

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

My issue is about claiming conformance. If the answer is that "we are 
non-conformant but we cannot change this because we are afraid of 
breaking legacy code" I would understand. But when the answer argues 
that they are conformant because in the particular case a warning is 
valid for establishing conformance, then I cannot understand it. We 
might as well say that any compiler which issues warnings whenever a 
compiler error should occur, simply because it can continue compiling, 
is a valid C or C++ conformant compiler.

I am sorry I brought this up In the Boost mailing list. Nobody really 
cares and this is not a Boost problem. I do apologize for voicing my 
displeasure here, or even trying to find out if this is really the way 
the standard is designed. It is not a Boost issue per se and I should 
have kept it to myself.