PATCH: Icky little array slice assignment bug

PATCH: Icky little array slice assignment bug

[Bart Schaefer]

This appears to date back about a year, roughly to Wayne's change to use
zero-based indexing internally on array subscripts (zsh-workers/11677).

zagzig% a=(x y z)
zagzig% echo $a[(i)q]
4
zagzig% echo $a[(I)q]
0
zagzig% a[(I)q]=W    
zagzig% echo $a
x y W x y z

The following patch fixes it, though I'm not sure it's the best way.

There remains this bug of extremely long standing:

zagzig% a[(r)q]=V
zagzig% echo $a
x y W x y z V		<-- this is ok
zagzig% a[(R)q]=U
zagzig% echo $a
U y W x y z V		<-- this is probably unexpected

That is, there's a phantom element at the right end of an array but not at
the left, so you can "push" but not "unshift" elements -- an attempt to
insert at the beginning of the array clobbers the first element.  We could
special-case an assignment to index zero when ksharrays is not in effect,
but it might be a bit messy.

Index: Src/params.c
===================================================================
--- Src/params.c	2001/05/02 16:59:02	1.6
+++ Src/params.c	2001/05/18 17:13:17
@@ -1721,7 +1721,7 @@
 		 v->pm->nam, 0);
 	    return;
 	}
-	if (v->inv && unset(KSHARRAYS))
+	if (v->inv && unset(KSHARRAYS) && v->start > 0)
 	    v->start--, v->end--;
 	q = old = v->pm->gets.afn(v->pm);
 	n = arrlen(old);

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: Icky little array slice assignment bug

[Bart Schaefer]

I wrote:
}
} That is, there's a phantom element at the right end of an array but not at
} the left, so you can "push" but not "unshift" elements -- an attempt to
} insert at the beginning of the array clobbers the first element.

Looking back at the ChangeLog-Release for several of the patches related
to 11677 caused me to try this:

zagzig% a[1,0]=(a b c)
zagzig% echo $a
a b c
zagzig% a[1,0]=(x y z)
zagzig% echo $a
x y z a b c

Well, whaddya know; you CAN do an "unshift", you just have to use a
seemingly-impossible range to accomplish it.

However, it demonstrates that my first patch didn't cover all cases (so
I have not committed it yet):

zagzig% a=(a b c)
zagzig% a[2,(R)q]=x
zagzig% echo $a
a x a b c
zagzig% a[3,(R)q]=y
zagzig% echo $a
a x y a x a b c

I'm not quite sure what to do about this.  Wayne?

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: Icky little array slice assignment bug

[Wayne Davison]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1655 bytes --]

On Fri, 18 May 2001, Bart Schaefer wrote:
> zagzig% a=(x y z)
> zagzig% a[(I)q]=W
> zagzig% echo $a
> x y W x y z

I patched this in a similar way to your diff, but I also made a[(I)q]=W
prepend the 'W' to the array.

> x y W x y z V		<-- this is ok
> zagzig% a[(R)q]=U
> zagzig% echo $a
> U y W x y z V		<-- this is probably unexpected

This is because we currently have a[0] as an alias for a[1].  Did we
have a good reason for that?  I think it would make more sense to have
a[0] return an empty string, while setting it should prepend an element
to the array.  My appended patch goes this route.

> Well, whaddya know; you CAN do an "unshift", you just have to use a
> seemingly-impossible range to accomplish it.

You can also insert a new element anywhere with something like
"a[3,2]=middle".  I think that this is a good thing.

> zagzig% a=(a b c)
> zagzig% a[2,(R)q]=x
> zagzig% echo $a
> a x a b c

Yeah, that's really non-intuitive, isn't it?  You actually told zsh that
you wanted all elements before 2 ("a") before the new string, and all
the elements after 0, ("a b c") after the string.  I think that this
should work the same as a[2,1] -- i.e. it should insert the string
without duplicating any existing elements.  My patch also does this.

If we decide that changing a[0] is a bad idea, I can change $a[(R)q]
to return an empty string when there is no match (rather than the first
element of the array), and I could even make "a[(R)q]=prepend" work
without affecting "a[0]=newfirstelement".  I had such a patch all worked
up when I decided that a[0] should just behave consistently no matter
where the 0 came from.

Thoughts?

..wayne..

[-- Attachment #2: Array fixes --]
[-- Type: TEXT/PLAIN, Size: 581 bytes --]

Index: Src/params.c
@@ -1252,8 +1252,6 @@
 	    }
 	    if (start > 0)
 		start--;
-	    else if (start == 0 && end == 0)
-		end++;
 	    if (s == tbrack) {
 		s++;
 		if (v->isarr && start == end-1 && !com &&
@@ -1721,8 +1719,13 @@
 		 v->pm->nam, 0);
 	    return;
 	}
-	if (v->inv && unset(KSHARRAYS))
-	    v->start--, v->end--;
+	if (v->inv && unset(KSHARRAYS)) {
+	    if (v->start > 0)
+		v->start--;
+	    v->end--;
+	}
+	if (v->end < v->start)
+	    v->end = v->start;
 	q = old = v->pm->gets.afn(v->pm);
 	n = arrlen(old);
 	if (v->start < 0) {

Re: PATCH: Icky little array slice assignment bug

[Wayne Davison]

I committed the non-controversial part of my array-assignment patch.
The second hunk of my params.c diff that just improved the boundary
checking (avoiding the weird cases you sited).  I have not (yet?)
changed array[0]'s meaning nor have I implemented the alternate
solution I proposed, pending further comments.

..wayne..

Re: PATCH: Icky little array slice assignment bug

[Bart Schaefer]

On May 20,  2:25am, Wayne Davison wrote:
}
} I have not (yet?) changed array[0]'s meaning nor have I implemented
} the alternate solution I proposed, pending further comments.

I like the simpler solution rather than the complicated one, in spite
of the slight ksharrays oddity.

We could add an option for it.  `setopt SUB_ZERO', anyone? :-)

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net