local variable setting problem/bug

local variable setting problem/bug

[Robert F Tobler]

I encountered the following problem when writing a function (this is in zsh  
3.00 on Nextstep, confirmed in zsh 3.01 on Nextstep, zsh 3.00 on Irix and zsh  
2.6-beta13 on linux:

I wanted to create local variables and set them to empty lists (could  
probably done more elegantly, or is maybe unnecessary, but I did it this way):

    myfun ()
    {
	local aopt=() eopt=() dopt=()
	...	

Since the 'locality' did not work I found out that introducing the empty  
lists produced the following effect (using 'functions' to print out what zsh  
thinks about 'myfun'):

    myfun () {
	    local aopt= () {
		    eopt=() dopt=()
	    }
	    ...

This in itself is highly nonintuitive: I guess the first =() is interpreted
as a start of a new function definition, as opposed to a variable
initialization the way I think it should be (or am I mistaken? - I haven't
programmed zsh all that long).

But even worse than that, try the following function:

    bug()
    {
	local a=()
	local b
	local c
    }

On Nextstep 3.3 running zsh 3.00 or zsh 3.01 (with -f option) I get:
	zsh: 24224 segmentation fault  zsh -f

On Linux 1.3.52 running zsh 2.6-beta13 I get (after a while):
	zsh: fatal error: out of memory

And on Irix 5.2 running zsh 3.00 it also consumes memory and
won't terminate normally.

Nevertheless I am very fond of zsh, and therefore I hope you can fix this problem!

------------------------------------------------------------------------
  Robert F. Tobler                 -  tel:+43(1)58801-4585,fax:5874932
  Institute of Computer Graphics   -  mailto:rft@cg.tuwien.ac.at
  Vienna University of Technology  -  http://www.cg.tuwien.ac.at/~rft/

Re: local variable setting problem/bug

[Zoltan Hidvegi]

> But even worse than that, try the following function:
> 
>     bug()
>     {
> 	local a=()
> 	local b
> 	local c
>     }
> 
> On Nextstep 3.3 running zsh 3.00 or zsh 3.01 (with -f option) I get:
> 	zsh: 24224 segmentation fault  zsh -f
> 
> On Linux 1.3.52 running zsh 2.6-beta13 I get (after a while):
> 	zsh: fatal error: out of memory
> 
> And on Irix 5.2 running zsh 3.00 it also consumes memory and
> won't terminate normally.

That's not surprising since local a=() in fact defined a function local and
a function a= which executed local b.  So the function called local
recursively calls itself and there is not exit from this recursion.  You
probably wanted to use it as

bug() {
	local a
	a=()
	...
}

You cannot initialise local variables with an array at declaration.  You
must use a separate assignment for that.

Zoltan

Re: local variable setting problem/bug

[Hrvoje Niksic]

Zoltan Hidvegi (hzoli@cs.elte.hu) wrote:
> That's not surprising since local a=() in fact defined a function local and
> a function a= which executed local b.  So the function called local
> recursively calls itself and there is not exit from this recursion.
> You

Couldn't zsh check its recursion depth?  It shouldn't be too hard to
implement, and would be a win in these cases.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

Re: local variable setting problem/bug

[Zoltan Hidvegi]

Hrvoje Niksic wrote:
> Couldn't zsh check its recursion depth?  It shouldn't be too hard to
> implement, and would be a win in these cases.

That was already discussed some time ago.  The problem is that one may want
to use recursive functions on purpose and an artificial limit is
undesirable here.

Zoltan

Re: local variable setting problem/bug

[Hrvoje Niksic]

Zoltan Hidvegi (hzoli@cs.elte.hu) wrote:
> Hrvoje Niksic wrote:
> > Couldn't zsh check its recursion depth?  It shouldn't be too hard to
> > implement, and would be a win in these cases.
> 
> That was already discussed some time ago.  The problem is that one may want
> to use recursive functions on purpose and an artificial limit is
> undesirable here.

Of course.  But the artificial limit can be set quite high, so that it
server _only_ to prevent core dumps.  E.g. XEmacs has max-specpdl-size
set to 3000.  I suppose it could be easy to add an ulimit-like
mechanism to control this value.

What do you think of that?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.