Patch for compilation on msvc

I’m not as adroit in interpreting the C99 standard as others, but I believe that one could interpret the prose of the standard to say that the loop condition has a different scope than the loop body, or at least variables declared in within the parentheses of “for(…)” are visible to the other expressions in the for(…) (variables declared in the loop body are not visible to subexpression representing the loop condition or the optional “increment” expression) (6.8.5.3):

The statement

for ( clause-1 ;expression-2 ;expression-3 ) statement

behaves as follows: The expression “expression-2” is the controlling expression that is evaluated before each execution of the loop body. The expression “expression-3” is evaluated as a void expression after each execution of the loop body. If clause-1is a declaration, the scope of any variables it declares is the remainder of the declaration and the entire loop, including the other two expressions; it is reached in the order of execution before the first evaluation of the controlling expression.

That’s true, but the {}'s introduce a new scope. VC++ has bugs in this area, and we’ve hit them in other parts of LLVM. I’d just suggest renaming the inner E to work around this…

-Chris

Mainly project change but also a few missing std include header and one
compiler bug (or not, I don’t know what the standard say):

for (GRExprEngine::null_iterator I=CheckerState->null_begin(),
E=CheckerState->null_end(); I!=E; ++I) {

const PostStmt& L = cast((I)->getLocation());
Expr
E = cast(L.getStmt());

Diag.Report(FullSourceLoc(E->getExprLoc(), Ctx.getSourceManager()),
diag::chkr_null_deref_after_check);
}

Not Expr* E who redefine E from the for initialization. Is it the same
scope? The strangest thing was that MSVC didn’t complain about redefinition
but seemed to ignore the Expr* E; definition and was thinking E was a
null_iterator. Took me some time to understand the problem.

I’m not as adroit in interpreting the C99 standard as others, but I believe that one could interpret the prose of the standard to say that the loop condition has a different scope than the loop body, or at least variables declared in within the parentheses of “for(…)” are visible to the other expressions in the for(…) (variables declared in the loop body are not visible to subexpression representing the loop condition or the optional “increment” expression) (6.8.5.3):

The statement

for ( clause-1 ;expression-2 ;expression-3 ) statement

behaves as follows: The expression “expression-2” is the controlling expression that is evaluated before each execution of the loop body. The expression “expression-3” is evaluated as a void expression after each execution of the loop body. If clause-1is a declaration, the scope of any variables it declares is the remainder of the declaration and the entire loop, including the other two expressions; it is reached in the order of execution before the first evaluation of the controlling expression.

That’s true, but the {}'s introduce a new scope.

Yes indeed; that’s what I was trying to say.

VC++ has bugs in this area, and we’ve hit them in other parts of LLVM. I’d just suggest renaming the inner E to work around this…

Of course! The name clash was unintentional to start with.