* PATCH: Icky little array slice assignment bug
@ 2001-05-18 17:34 Bart Schaefer
2001-05-18 18:16 ` Bart Schaefer
0 siblings, 1 reply; 5+ messages in thread
From: Bart Schaefer @ 2001-05-18 17:34 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: PATCH: Icky little array slice assignment bug
2001-05-18 17:34 PATCH: Icky little array slice assignment bug Bart Schaefer
@ 2001-05-18 18:16 ` Bart Schaefer
2001-05-19 12:13 ` Wayne Davison
0 siblings, 1 reply; 5+ messages in thread
From: Bart Schaefer @ 2001-05-18 18:16 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: PATCH: Icky little array slice assignment bug
2001-05-18 18:16 ` Bart Schaefer
@ 2001-05-19 12:13 ` Wayne Davison
2001-05-20 9:25 ` Wayne Davison
0 siblings, 1 reply; 5+ messages in thread
From: Wayne Davison @ 2001-05-19 12:13 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-workers
[-- 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) {
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: PATCH: Icky little array slice assignment bug
2001-05-19 12:13 ` Wayne Davison
@ 2001-05-20 9:25 ` Wayne Davison
2001-05-20 21:31 ` Bart Schaefer
0 siblings, 1 reply; 5+ messages in thread
From: Wayne Davison @ 2001-05-20 9:25 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-workers
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..
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: PATCH: Icky little array slice assignment bug
2001-05-20 9:25 ` Wayne Davison
@ 2001-05-20 21:31 ` Bart Schaefer
0 siblings, 0 replies; 5+ messages in thread
From: Bart Schaefer @ 2001-05-20 21:31 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-05-20 21:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-05-18 17:34 PATCH: Icky little array slice assignment bug Bart Schaefer
2001-05-18 18:16 ` Bart Schaefer
2001-05-19 12:13 ` Wayne Davison
2001-05-20 9:25 ` Wayne Davison
2001-05-20 21:31 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).