[antlr-interest] Apparent problem with dynamic scopes in C target

[Daniel Jensen]

Jim Idle wrote:
> Fixed in the templates. You need last nights jar.

That's what I was using.  The code in my parser that seems to be causing 
the trouble is:

    $ExprScope::in_extract = $ExprScope[-1]::in_extract;

which gets turned into this C code:

    (SCOPE_TOP(ExprScope))->in_extract=     
((SCOPE_TYPE(ExprScope))(ctx->SCOPE_STACK(ExprScope)->get( 
ctx->SCOPE_STACK(ExprScope), 
ctx->SCOPE_STACK(ExprScope)->size(ctx->SCOPE_STACK(ExprScope)) - 1 - 1) 
))->in_extract;

The change you made to C.stg changes the definition of SCOPE_SIZE, but 
the generated code doesn't use SCOPE_SIZE, so the behavior is 
unchanged.  Maybe the fix is to generate different code for 
$ExprScope[-1] that uses the SCOPE_SIZE macro?

>>   
>>>> On another note, I will admit to being slightly baffled by 
>>>> 'exprScopeDepth' - is it correct that it's only ever incremented?
>>>>   
>>>>       
>>> Er, yeah ... I'm sure I would have noticed that eventually. :-/  Just 
>>> pretend that there are @after actions that decrement exprScopeDepth 
>>> following the @init actions that increment it.
>>>     
>> :-)
>> You could use SCOPE_SIZE(ExprScope);
> You must use this.

Why, if the program that uses the parser only has a single thread?  I'm 
actually targeting both C and Java with this grammar, so the fewer C 
target-specific constructs I'm forced to use, the happier I'll be.

>>  this ought to do exactly the same 
>> thing with less chance of mistakes, as well as being more threadsafe 
>> (@members generates global variables in the C backend, scopes are local 
>> to the parser's context).
>>   
>
> Jim

Excellent points, and I may end up taking this advice, but I don't 
understand why my alternative is unworkable.


Daniel