<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, May 1, 2014 at 1:52 PM, Volker Diesel <span dir="ltr"><<a href="mailto:volker.diesel@web.de" target="_blank">volker.diesel@web.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> Hi David.<br>
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.<br>
</blockquote><div><br></div><div>Sorry, but you've lost a lot of credibility through this message. We do care deeply about following the relevant language standards, but:</div><div> 1) This warning is not part of any standard we follow,</div>
<div> 2) The -E flag (or, indeed, any preprocessing-only mode) is not part of the C++ standard (but is part of POSIX),</div><div> 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</div>
<div> 4) Given the behavior of -E (as defined by POSIX), it must expand macros by default.</div><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
BR<br>
Volker<br>
<br>
--<br>
Diese Nachricht wurde von meinem Android Mobiltelefon mit <a href="http://WEB.DE" target="_blank">WEB.DE</a> Mail gesendet.<br>
<br>
"David Blaikie [via Clang Developers]" &<a href="mailto:lt%3Bml-node%2Bs42468n4039196h92@n3.nabble.com">lt;ml-node+s42468n4039196h92@n3.nabble.com</a>> schrieb:<br>
<div class=""><br>
On Wed, Mar 12, 2014 at 7:13 AM, Richtarsky, Martin<br>
</div> < [hidden email] > wrote:<br>
> Hi,<br>
><br>
> is this expected behavior?<br>
<div class=""><br>
To answer this original question: Yes, it is expected behavior that<br>
preprocessing source and compiling it does not produce the same<br>
results as compiling the preprocessed source directly.<br>
<br>
Certain warnings produce (too many) false positives without taking<br>
into account whether they were expanded from a macro, etc.<br>
<br>
Take, for example:<br>
<br>
#define FUNC_TEST(arg) (func(arg) ? GOOD : BAD)<br>
<br>
</div> Perhaps this macro is the idiomatic way to call 'func' in this<br>
library? (ie: 'func' is an internal name, only ever meant to be<br>
<div class=""> accessed via the macro)<br>
<br>
Sometimes the user wants the result:<br>
<br>
if (FUNC_TEST(42) == GOOD) { ... }<br>
<br>
</div> but sometimes it's not needed:<br>
<div class=""><br>
FUNC_TEST(42);<br>
<br>
Which all seems fine. But if the user explicitly wrote:<br>
<br>
func(arg) ? GOOD : BAD;<br>
<br>
we would like to warn the user that they have unused-values there?<br>
(Why would anyone /ever/ write that code? The whole conditional<br>
operator and the values GOOD and BAD are discarded, the user might as<br>
</div> well just write "func(arg);")<br>
<div class=""><br>
So using the presence/absence of a macro helps diagnose the bad cases<br>
while not needlessly warning on reasonable cases.<br>
<br>
</div> To your later comment about "no other compiler does this" - I suspect<br>
some do, but also one of Clang's engineering novelties is that it<br>
<div class=""> keeps track of all this macro expansion information so it /can/ reason<br>
</div> about warnings using this information. Many other compilers don't have<br>
<div class=""> this information available to make such choices about when to emit and<br>
suppress warnings.<br>
<br>
- David<br>
<br>
<br>
</div> ><br>
> cat preproc_warning.sh<br>
> #!/bin/bash<br>
><br>
> echo "-- direct compilation:"<br>
> clang++ -c preproc_warning.cpp -o /dev/null<br>
> echo "-- preprocessing:"<br>
> clang++ -E preproc_warning.cpp -o preproc_out.cpp<br>
> echo "-- compilation of preprocessed source:"<br>
> clang++ -c preproc_out.cpp -o /dev/null<br>
><br>
><br>
> cat preproc_warning.cpp<br>
> #include <stddef.h><br>
><br>
> #define CHECK(a) ( a ? 1 : NULL)<br>
><br>
> int func1()<br>
> {<br>
> int a;<br>
> return NULL; // produces warning during direct compilation and compilation of preprocessed source<br>
> }<br>
><br>
> int func2()<br>
> {<br>
> int a;<br>
> return (CHECK(a)); // produces warning only on preprocessed source<br>
> }<br>
><br>
><br>
> shows this output:<br>
> -- direct compilation:<br>
> preproc_warning.cpp:8:12: warning: implicit conversion of NULL constant to 'int' [-Wnull-conversion]<br>
> return NULL; // produces warning during direct compilation and compilation of preprocessed source<br>
> ~~~~~~ ^~~~<br>
> 0<br>
> 1 warning generated.<br>
> -- preprocessing:<br>
> -- compilation of preprocessed source:<br>
> preproc_warning.cpp:8:12: warning: implicit conversion of NULL constant to 'int' [-Wnull-conversion]<br>
> return __null;<br>
> ~~~~~~ ^~~~~~<br>
> 0<br>
> preproc_warning.cpp:14:23: warning: implicit conversion of NULL constant to 'int' [-Wnull-conversion]<br>
> return (( a ? 1 : __null));<br>
> ~~~~~~ ^~~~~~<br>
> 0<br>
> 2 warnings generated.<br>
><br>
><br>
> Best regards,<br>
> Martin<br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> [hidden email]<br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
[hidden email]<br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
<br>
<br>
<br>
If you reply to this email, your message will be added to the discussion below:<br>
<br>
<a href="http://clang-developers.42468.n3.nabble.com/Warnings-are-different-on-preprocessed-file-tp4038408p4039196.html" target="_blank">http://clang-developers.42468.n3.nabble.com/Warnings-are-different-on-preprocessed-file-tp4038408p4039196.html</a><br>
<br>
<br>
To unsubscribe from Warnings are different on preprocessed file, click here .<br>
NAML<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://clang-developers.42468.n3.nabble.com/Warnings-are-different-on-preprocessed-file-tp4038408p4039232.html" target="_blank">http://clang-developers.42468.n3.nabble.com/Warnings-are-different-on-preprocessed-file-tp4038408p4039232.html</a><br>
<div class="im">Sent from the Clang Developers mailing list archive at Nabble.com.<br>
</div><div class=""><div class="h5">_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>