[cfe-dev] Patch for compilation on msvc

[Chris Lattner]

On Feb 17, 2008, at 11:59 AM, Ted Kremenek wrote:

>
> 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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080217/9ac87760/attachment.html>