* 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).