On Feb 16, 2008, at 2:21 PM, Cédric Venet wrote:
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<PostStmt>((*I)->getLocation());
Expr* E = cast<Expr>(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._______________________________________________
cfe-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
