Subject: Re: [boost] Bug report rejected as conformant
From: Mehdi AMINI (joker.eph_at_[hidden])
Date: 2018-01-13 23:06:47
2018-01-13 13:43 GMT-08:00 Edward Diener via Boost <boost_at_[hidden]>:
> On 1/13/2018 4:08 PM, Marc Glisse via Boost wrote:
>> On Sat, 13 Jan 2018, Edward Diener via Boost wrote:
>> On 1/13/2018 1:55 PM, Marc Glisse via Boost wrote:
>>>> On Sat, 13 Jan 2018, Edward Diener via Boost wrote:
>>>> I recently reported a preprocessor bug in Oracle C++ 12.6 on their
>>>>> online forum when compiling a C program example. I even cited the C11
>>>>> standard in showing that Oracle C++ 12.6's actions were non-conformant. The
>>>>> answer I was given, from an Oracle C++ developer who said he was a member
>>>>> of the C++ standard committee, is that since Oracle C++ 12.6 gives a
>>>>> warning message rather than a compiler error the compiler was compliant
>>>>> with the C standard, since the standard only requires a diagnostic message
>>>>> to be considered standard compliant when it does not implement the compiler
>>>>> according to the standard, and that a warning was a diagnostic message.
>>>>> Furthermore since there was a way to force the particular warning to be
>>>>> considered an error, Oracle was not going to change their compiler. At that
>>>>> point I "lost it" so to speak.
>>>>> I cannot conceive that any C/C++ standard would specify that giving a
>>>>> warning rather than an error, when not complying with the C/C++ standard,
>>>>> would then make the compiler compliant. Comments ?
>>>> Uh, that's what all compilers do all the time when they implement
>>>> extensions to the standard. With gcc, you even need to specify -Wpedantic
>>>> to get those required diagnostics. I am really surprised that this is the
>>>> first compiler for which you notice this...
>>> 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 ? Or do you believe there is no
> such thing as following the C++ standard so whatever a compiler does it is
> perfectly OK to call itself compliant ?
>> 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.
>> 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.
>> since the compiler is "inventing" a standard which does not exist ?
>>> Note that the error I reported was not when using any
>>> -std=some_compilers_extension mode ( as in gcc's -std=gnu++nn mode as
>>> opposed to -std=c++nn mode) but with -std=c11 mode, which is explained as
>>> being an implementation of the c11 standard. In other words if I were using
>>> an Oracle c11 mode, as in a hypothetical -std=oracle++c11, I would not have
>>> complained about their extension to the standard or their cavalier
>>> treatment of a bug as not being a bug because they produced a warning. But
>>> that was not the case and the mode being used was the -std=c11 mode, which
>>> evidently means to Oracle C++ whatever they feel like defining as the c11
>>> standard even if it does not follow the actual c11 standard.
>> Again, this is in no way specific to Oracle's compiler.
> 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".
>> I am still trying to figure out why you are getting so angry about it. If
>> the extension was breaking some subtle sfinae detection code, I could
>> understand, but the preprocessor cannot be involved there. Does it break
>> some feature detection in a configuration script? That's one case where
>> indeed warnings can be much less helpful than errors, but I would still be
>> surprised if that is the case you are in.
>> (maybe I should read your bug report before posting anything else...)
> My anger is wrong. But my point of view is I believe valid.
Actually I haven't read where you clearly develop your point with respect
to the standard, even though you felt like asking from others to "quote an
actual place rather than a random sentence".
> Why waste time trying to test a compiler when the result is that the
> compiler developers do not care if they have a bug in their implementation
> because all they have to do is tell you that their warning satisfies the
> standard and therefore there is no point of fixing their bug. I don't care
> what the bug actually is in this case, it's the attitude of the compiler
> implementor that irks me.
The C++ standard says: "If a program contains a violation of any
diagnosable rule or an occurrence of a construct described in this Standard
as âconditionally-supportedâ when the implementation does not support that
construct, a conforming implementation shall issue at least one diagnostic
message." (C++14 18.104.22.168).
It also define "diagnostic message" as "message belonging to an
implementation-defined subset of the implementationâs output messages"
Finally the standard also allows the compiler vendor to compile and execute
an ill-formed program, as long as they don't alter the behavior of a well
conformant program: "A conforming implementation may have extensions
(including additional library functions), provided they do not alter the
behavior of any well-formed program. Implementations are required to
diagnose programs that use such extensions that are ill-formed according to
this International Standard. Having done so, however, they can compile and
execute such programs." (C++14 1.4.8).
I believe that compiler vendors in general are very much more listening to
bug exhibited in standard-compliant programs than "bugs" exhibited by
PS: what is the relationship with Boost and/or this mailing-list by the way?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk