Re: Parser bugs: "local a=()"

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Sun, 12 Jul 2015 18:13:18 +0900 (JST)
ryosuke_i_628@xxxxxxxxxxx wrote:
> func4() {
>   local a=()
>   local b=false
>   echo "a in func4 length: ${#a[@]}"
> }
> example@local:~$ func4
>  a in func4 length: 0
>  [1]  135208 segmentation fault  zsh
  
Parsing of this has changed recently (since 5.0.8), but you can see what
the effect is by doing (whatever the version)

func4() {
  \local a=()
  \local b=false
  echo "a in func4 length: ${#a[@]}"
}

(this suppresses the new special parsing of "local").

Running this gives me:

 :3: maximum nested function level reached

with no segmentation violation, but I would guess the recursive call is
the key to the problem --- there's no robust way for the shell to find
out it's used as many resources and it can and unwind safely, so the
builtin limit is just a guess whose effect is highly system dependent and
that tends to get worse as time goes on and specs change.

You can see why by doing:

  functions local
  local () {
	\local b=false
  }

What's happened is the multiple function definition code has defined
functions called "local" and "a=" with the body on the next
line (as there are no braces, it's a single line definition). "\local
b=false".  So invoking local causes infinite recursion.

At the time, this was actually correct parsing according to the rules in
force, if extremely obscure.

Things you can do to protect yourself (apart from upgrading to the next
release, currently vapourware) include "unsetopt multifuncdef" to
disallow the also rather obscure and not often used feature of defining
multiple functions in one go.

When something like this  has come up before. we've never managed to
work out a safer way of handling recursive functions that's both robust
and non-intrusive, i.e. doesn't forbid useful behaviour.

pws