[cfe-dev] Warnings are different on preprocessed file
Volker Diesel
volker.diesel at web.de
Fri May 2 12:58:08 PDT 2014
Well, the string "preprocess" occurrs roughly 200 times in C++ standard, therefore I doubt that preprocessing is "not part of the C++ standard".
True enough, C++ standard is not always very clear about preprocessing and leaves much space for interpretation. However, as already mentioned, C++ standard only talks about "preprocessing tokens", what (in my understanding) suggests, that preprocessing is a purely lexical operation and shouldn't have any impact on semantics (as is the case with clang).
I never received a response to my question, from which statement of C++ standard (or any other standards for that matter) clang developers come to the conclusion, that preprocessing might have impact on compiler's warning semantics.
Furthermore, if C++ standard (or any other standard) is "fuzzy" and leaves room for interpretation, I would expect an implementation of that standard to consider the ambiguity and provide options / switches for enforcing this or that interpretation. Hey, I only asked for a compiler switch in order to make clang warnings in case of compilation of preprocessed files compatible with clang's warnings in case of direct compilation of source files. I did not ask for changing clang's default behavior, nor did I ask for any incompatible changes, nor did I question the reasons, why clang team implemented it the way, it currently is. But again, I didn't get any response to my question, and I don't get the point yet, why such a compiler switch would be a "bad thing" for clang.
If someone told me, that it's technically not possible or too much effort for this or that technical reason, I would (have to) live with it, but simply saying "No" on the ground that someone considers her/his interpretation of C++ standard superior to other people's interpretation doesn't seem to be a good solution (at least to me).
And finally... Software, that is not flexible enough to adapt to different user's requirements, will not survive long-term. That's my conviction and part of my professional experience.
Gesendet: Donnerstag, 01. Mai 2014 um 23:57 Uhr
Von: "Richard Smith [via Clang Developers]" <ml-node+s42468n4039234h70 at n3.nabble.com>
An: "Volker Diesel" <volker.diesel at web.de>
Betreff: Re: Warnings are different on preprocessed file
On Thu, May 1, 2014 at 1:52 PM, Volker Diesel < [hidden email] > wrote:
Hi David.
Great to hear that clang development reserves it's right to be different and to ignore objections regarding C++ standard Let's wait and see to where this policy leeds. I have enough professional experience to know what will come out of this attitude.
Sorry, but you've lost a lot of credibility through this message. We do care deeply about following the relevant language standards, but:
1) This warning is not part of any standard we follow,
2) The -E flag (or, indeed, any preprocessing-only mode) is not part of the C++ standard (but is part of POSIX),
3) Given our desire to minimize false positives from our warning, it's our judgement that our users are best served by suppressing the warning in certain cases involving macros, and
4) Given the behavior of -E (as defined by POSIX), it must expand macros by default.
If you're going to be passing the result of -E back to Clang or another compiler, use -frewrite-includes to avoid problems such as this one -- that's the very reason why we have that flag, and other distributed build systems are using this to great effect.
BR
Volker
--
Diese Nachricht wurde von meinem Android Mobiltelefon mit WEB.DE Mail gesendet.
"David Blaikie [via Clang Developers]" & [hidden email] > schrieb:
On Wed, Mar 12, 2014 at 7:13 AM, Richtarsky, Martin
< [hidden email] > wrote:
> Hi,
>
> is this expected behavior?
To answer this original question: Yes, it is expected behavior that
preprocessing source and compiling it does not produce the same
results as compiling the preprocessed source directly.
Certain warnings produce (too many) false positives without taking
into account whether they were expanded from a macro, etc.
Take, for example:
#define FUNC_TEST(arg) (func(arg) ? GOOD : BAD)
Perhaps this macro is the idiomatic way to call 'func' in this
library? (ie: 'func' is an internal name, only ever meant to be
accessed via the macro)
Sometimes the user wants the result:
if (FUNC_TEST(42) == GOOD) { ... }
but sometimes it's not needed:
FUNC_TEST(42);
Which all seems fine. But if the user explicitly wrote:
func(arg) ? GOOD : BAD;
we would like to warn the user that they have unused-values there?
(Why would anyone /ever/ write that code? The whole conditional
operator and the values GOOD and BAD are discarded, the user might as
well just write "func(arg);")
So using the presence/absence of a macro helps diagnose the bad cases
while not needlessly warning on reasonable cases.
To your later comment about "no other compiler does this" - I suspect
some do, but also one of Clang's engineering novelties is that it
keeps track of all this macro expansion information so it /can/ reason
about warnings using this information. Many other compilers don't have
this information available to make such choices about when to emit and
suppress warnings.
- David
>
> cat preproc_warning.sh
> #!/bin/bash
>
> echo "-- direct compilation:"
> clang++ -c preproc_warning.cpp -o /dev/null
> echo "-- preprocessing:"
> clang++ -E preproc_warning.cpp -o preproc_out.cpp
> echo "-- compilation of preprocessed source:"
> clang++ -c preproc_out.cpp -o /dev/null
>
>
> cat preproc_warning.cpp
> #include <stddef.h>
>
> #define CHECK(a) ( a ? 1 : NULL)
>
> int func1()
> {
> int a;
> return NULL; // produces warning during direct compilation and compilation of preprocessed source
> }
>
> int func2()
> {
> int a;
> return (CHECK(a)); // produces warning only on preprocessed source
> }
>
>
> shows this output:
> -- direct compilation:
> preproc_warning.cpp:8:12: warning: implicit conversion of NULL constant to 'int' [-Wnull-conversion]
> return NULL; // produces warning during direct compilation and compilation of preprocessed source
> ~~~~~~ ^~~~
> 0
> 1 warning generated.
> -- preprocessing:
> -- compilation of preprocessed source:
> preproc_warning.cpp:8:12: warning: implicit conversion of NULL constant to 'int' [-Wnull-conversion]
> return __null;
> ~~~~~~ ^~~~~~
> 0
> preproc_warning.cpp:14:23: warning: implicit conversion of NULL constant to 'int' [-Wnull-conversion]
> return (( a ? 1 : __null));
> ~~~~~~ ^~~~~~
> 0
> 2 warnings generated.
>
>
> Best regards,
> Martin
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
If you reply to this email, your message will be added to the discussion below:
http://clang-developers.42468.n3.nabble.com/Warnings-are-different-on-preprocessed-file-tp4038408p4039196.html
To unsubscribe from Warnings are different on preprocessed file, click here .
NAML
--
View this message in context: http://clang-developers.42468.n3.nabble.com/Warnings-are-different-on-preprocessed-file-tp4038408p4039232.html
Sent from the Clang Developers mailing list archive at Nabble.com.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
If you reply to this email, your message will be added to the discussion below:
http://clang-developers.42468.n3.nabble.com/Warnings-are-different-on-preprocessed-file-tp4038408p4039234.html
To unsubscribe from Warnings are different on preprocessed file, click here .
NAML
--
View this message in context: http://clang-developers.42468.n3.nabble.com/Warnings-are-different-on-preprocessed-file-tp4038408p4039260.html
Sent from the Clang Developers mailing list archive at Nabble.com.
More information about the cfe-dev
mailing list