2018-01-13 13:43 GMT-08:00 Edward Diener via Boost <boost@lists.boost.org>:
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 1.4.2.2). It also define "diagnostic message" as "message belonging to an implementation-defined subset of the implementation’s output messages" (C++14 1.3.6). 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 non-compliant programs. PS: what is the relationship with Boost and/or this mailing-list by the way? Best, -- Mehdi