reply fail, sorry Now with more everyone (+Nico, +cfe-commits)! \o/ On Wed, May 16, 2012 at 9:41 AM, David Blaikie <[email protected]> wrote: > On Wed, May 16, 2012 at 1:02 AM, Chandler Carruth <[email protected]> > 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
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
