[cfe-dev] Warnings are different on preprocessed file
Richard Smith
richard at metafoo.co.uk
Thu May 1 14:54:37 PDT 2014
On Thu, May 1, 2014 at 1:52 PM, Volker Diesel <volker.diesel at web.de> 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]" &
> lt;ml-node+s42468n4039196h92 at n3.nabble.com> 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
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140501/4b72536a/attachment.html>
More information about the cfe-dev
mailing list