[cfe-commits] r156901 - in /cfe/trunk: include/clang/Sema/Sema.h lib/Parse/ParseStmt.cpp lib/Sema/SemaExprCXX.cpp test/SemaCXX/conversion.cpp

David Blaikie dblaikie at gmail.com
Thu May 17 14:06:09 PDT 2012

reply fail, sorry
Now with more everyone (+Nico, +cfe-commits)! \o/

On Wed, May 16, 2012 at 9:41 AM, David Blaikie <dblaikie at gmail.com> wrote:
> On Wed, May 16, 2012 at 1:02 AM, Chandler Carruth <chandlerc at google.com> wrote:
>> I have to ask: why do we bother warning about 'if (NULL) {...}'? It seems
>> obvious and valid code, with no plausible typo or mistake in it.
> Because it's easier to warn about it than avoid warning about it,
> given the way the conversion checking code works.
>> I don't understand why we need such heavy machinery merely to suppress this *iff*
>> the NULL comes out of some other macro...
> The heavy machinery is to suppress the general case where the
> conversion context is outside a macro (such as an if, a function call,
> etc) and the NULL use is inside a macro. In particular:
> #define FOO ((x) ? y : NULL)
> if (FOO)
>  FOO->stuff
> The way the conversion warnings are done is that the full expression
> is examined without any context about where it came from (except now
> I've plumbed through the SourceLocation conversion context) so there
> would be no way to differentiate the case of a full expression in a
> condition compared to any other full (or even sub)expression to filter
> out these cases in that way. I think plumbing the SourceLocation
> information through seems useful/correct, and helps catch the specific
> case - to filter out this warning when used at the top level (which
> isn't even the case that Nico reported, since it's nested inside a
> conditional) of a condition expression would require passing through
> some other, even more specific, data to check in the SemaChecking.
> Though I'm open to other ideas - that's at least my understanding of
> the situation/what you were asking about,
> - David

More information about the cfe-commits mailing list