Re: possible bug: stack dump with <<-String, #{...} and large loops

Hi,

At Wed, 29 May 2002 20:01:37 +0900,
ts wrote:
> n> But it means to push a dummy dvar *after* the expression.
>  
>  No it is in top_local_init(), i.e. this will be the first node executed by
>  ruby when it enter in "#{...}"

I see.

> n> [ruby-core:00053] pushes a dummy dvar *before* NODE_DSTR etc.
> 
>  and this is an error for the case
> 
>    "#{a = 12}"
>    eval "x = 12"
> 
>  `x' is now a dynamic variable, where normally it must be a local variable.

Yes, but is it really a problem?  And it will be a dvar even if
DASGN is added in top_local_init().

> >> If I'm right ruby just need to test if the number of local variable was
> >> modified before executing the nodes (i.e. just after the label default: in
> >> NODE_DSTR). If this is true it must reallocate ruby_scope->local_vars and
> >> perhaps remake 'ruby_scope->local_tbl = node->nd_tbl'
> 
> n> How about variables defined in eval?
> 
>  I don't see where is the problem : ruby must execute the node (in
>  NODE_DSTR) with the right value for ruby_scope->local_vars and
>  ruby_scope->local_tbl, this is why it must test if it has the right value
>  before executing the nodes (because another thread has modified it, this

If a variable has been defined in eval as non-dynamic, its
location may conflict with a variable defined in NODE_EVSTR
compiled by anothrer thread.

-- 
Nobu Nakada