Re: PATCH: Re: PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset

Re: PATCH: Re: PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Feb 12,  9:33am, Bart Schaefer wrote:
> } Subject: Re: PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset
> } 
> } zagzig% foo() { echo $# "$@" }
> } zagzig% foo "$unset[@]"
> } zsh: segmentation fault (core dumped)  Src/zsh -f
> 
> Here's a fix.  I don't think this can possibly cause anything else to go
> wrong, but ...

...it broke multiple subscripts. The patch below fixes this in a way
that hopefully will not cause anything else to go wrong, but...

Seriously, the problem was that for multiple subscripts a temporary
pm-struct was created with a NULL nam. The patch makes such a
temporary get a nam equal to nulstring. Since such a temporary is
created only in one place this should not affect other uses (of
createparam() and getarrvalue()).

I found this while trying to `fix' the problem I mentioned in 7328:

Given an array `a=(a b b c d e f g)' an expression like this

  ${${a[1,4]}[(I)b]}

gives `3' (the offset of the last `b' in the first four
elements). But if the expression is used inside a subscript:

  ${a[${${a[1,4]}[(I)b]},-1]}

this returns the whole string because the first expression expands to
`0' (zero). This is caused by the call to parsestr() in getarg() which
makes the subscript be tokenized as if it where in double quotes. With
that the code in paramsubst() and friends turns ${a[1,4]} into one
string, making the [(I)b] fail. To get this to work one will have to
use ${a[${${(@)a[1,4]}[(I)b]},-1]}.

I don't want to change this now because I think that there are reasons
to use parsestr() instead of parse_subst_string() (which solves the
problem), but I think that this difference between using the same
expression outside of an subscript and inside one is quite irritating.
So, does anyone know of a case where we need the behavior parsestr()
gives?


Bye
 Sven

--- os/params.c	Mon Feb 15 12:51:43 1999
+++ Src/params.c	Thu Feb 18 11:20:15 1999
@@ -568,8 +568,10 @@
 
 	if (isset(ALLEXPORT) && !oldpm)
 	    flags |= PM_EXPORTED;
-    } else
+    } else {
 	pm = (Param) alloc(sizeof *pm);
+	pm->nam = nulstring;
+    }
     pm->flags = flags;
 
     if(!(pm->flags & PM_SPECIAL))

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset

[Peter Stephenson]

> } Sven Wischnowsky wrote:
> } >   % foo() { echo $# }
> } >   % unset a
> } >   % foo $a[@]
> } >   0                    # fine
> } >   % foo "$a[@]"
> } >   1                    # oops
> 
> That's not an "oops".  That's the way it's supposed to work.  Try the
> equivalent code in bash.

Bash doesn't even have arrays, apart from "$@", of course.  Try it in
ksh, and remember you need "${f[@]}" because the bracing rules are
more strict, and you'll find it elides the whole thing as with the
patch.

Taking a @ subscript was never a well-defined thing to do on a scalar,
whether or not it happens to be so with a zsh extension; its essential
purpose is to provide word splitting for arrays in strings, so zero
elements gives zero words.  (And if it leaves a null argument on the
line for an empty scalar, I would argue that's inconsistently
implemented.)

> I don't think we want this patch.

It seems pretty clear to me the shell is just plain broken without it.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset

[Bart Schaefer]

On Feb 12,  4:45pm, Peter Stephenson wrote:
} Subject: Re: PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset
}
} Try it in ksh, and remember you need "${f[@]}"

OK, I concur.  3.0.5 is broken in the same way, then.

However, with your patch, I get this:

zagzig% foo() { echo $# "$@" }
zagzig% foo "$unset[@]"
zsh: segmentation fault (core dumped)  Src/zsh -f


-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

PATCH: Re: PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset

[Bart Schaefer]

On Feb 12,  9:33am, Bart Schaefer wrote:
} Subject: Re: PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset
} 
} zagzig% foo() { echo $# "$@" }
} zagzig% foo "$unset[@]"
} zsh: segmentation fault (core dumped)  Src/zsh -f

Here's a fix.  I don't think this can possibly cause anything else to go
wrong, but ...

The first two hunks go on top of PWS's patch and simply expand a bit more
on the test he changed, to be sure no null pointers are dereferenced.

I'm not sure the test of the PM_UNSET flag is necessary, but it seemed
to fit the semantics.

The third hunk (still params.c) causes getarrvalue() to return an empty
array rather than NULL for an unset parameter.  There are just too many
uses of the result in paramsubst() to be sure they're all prepared to
handle a NULL.  Note that `nular' is an array consisting of one empty
element, which may be the wrong thing to return in the pre-existing (!v)
branch, but I'm not prepared to muck with that.

It bugs me a little that the code in paramsubst() seems to "accidentally"
do the right thing given this return value.  It really should explictly
check (isarr < 0) and (vunset) -- which combined mean an unset variable
that was subscripted with [@] -- rather than stumbling into the correct
branch because (aval[0] == 0), which is what happens now.  However ...

Index: Src/params.c
===================================================================
--- params.c	1999/02/12 17:10:43	1.27
+++ params.c	1999/02/13 06:55:01
@@ -246,6 +246,10 @@
 };
 #undef BR
 
+#define IS_UNSET_VALUE(V) \
+	((V) && (!(V)->pm || ((V)->pm->flags & PM_UNSET) || \
+		 !(V)->pm->nam || !*(V)->pm->nam))
+
 static Param argvparam;
 
 /* hash table containing the parameters */
@@ -966,7 +970,7 @@
     if (*tbrack == Outbrack)
 	*tbrack = ']';
     if ((s[0] == '*' || s[0] == '@') && s[1] == ']') {
-	if ((v->isarr || !v->pm || !*v->pm->nam) && s[0] == '@')
+	if ((v->isarr || IS_UNSET_VALUE(v)) && s[0] == '@')
 	    v->isarr |= SCANPM_ISVAR_AT;
 	v->a = 0;
 	v->b = -1;
@@ -1205,6 +1209,8 @@
 
     if (!v)
 	return arrdup(nular);
+    else if (IS_UNSET_VALUE(v))
+	return arrdup(&nular[1]);
     if (v->inv) {
 	char buf[DIGBUFSIZE];
 

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com