On Apr 29, 2013, at 10:33 , John McCall <[email protected]> wrote: > On Apr 26, 2013, at 2:42 PM, Jordan Rose <[email protected]> wrote: >> Author: jrose >> Date: Fri Apr 26 16:42:55 2013 >> New Revision: 180638 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=180638&view=rev >> Log: >> [analyzer] Model casts to bool differently from other numbers. >> >> Casts to bool (and _Bool) are equivalent to checks against zero, >> not truncations to 1 bit or 8 bits. >> >> This improved reasoning does cause a change in the behavior of the alpha >> BoolAssignment checker. Previously, this checker complained about statements >> like "bool x = y" if 'y' was known not to be 0 or 1. Now it does not, since >> that conversion is well-defined. It's hard to say what the "best" behavior >> here is: this conversion is safe, but might be better written as an explicit >> comparison against zero. >> >> More usefully, besides improving our model of booleans, this fixes spurious >> warnings when returning the address of a local variable cast to bool. >> >> <rdar://problem/13296133> >> >> Modified: >> cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp >> cfe/trunk/test/Analysis/bool-assignment.c >> cfe/trunk/test/Analysis/casts.c >> cfe/trunk/test/Analysis/stack-addr-ps.cpp >> cfe/trunk/test/Analysis/stackaddrleak.c >> >> Modified: cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp?rev=180638&r1=180637&r2=180638&view=diff >> ============================================================================== >> --- cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp (original) >> +++ cfe/trunk/lib/StaticAnalyzer/Core/SValBuilder.cpp Fri Apr 26 16:42:55 >> 2013 >> @@ -327,6 +327,22 @@ SVal SValBuilder::evalCast(SVal val, Qua >> if (val.isUnknownOrUndef() || castTy == originalTy) >> return val; >> >> + if (castTy->isBooleanType()) { > > For what it's worth, the fact that this has conversion-to-bool semantics > should be > fully encoded in the CastKind; is there a reason you don't always have that > here?
This has come up before (and most likely you've raised it before); we've thought of pushing the CastKind-switch from ExprEngineC down into SValBuilder, but haven't yet for a couple of reasons: - not all casts really fall under SValBuilder's jurisdiction - checkers that want to cast from one type to another shouldn't need to use an explicit cast kind - inertia Anyway, we'll probably revisit this again in the future, but I was trying to keep the patch fairly contained for now. Jordan _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
