[cfe-dev] Patch for compilation on msvc

[Ted Kremenek]

On Feb 17, 2008, at 12:04 PM, Chris Lattner wrote:

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080217/1c0016ac/attachment.html>