zsh v 2.6-beta13 bug (fwd)

zsh v 2.6-beta13 bug (fwd)

[mason]

I wrote:
::Additionally, on HP, after doing that, I can sometimes crash zsh, if I do:
::1. '~' (as described above)
::2. 'j' 'k' 'j' 'k'... (until there's a beep)
:?? You shouldn't get a beep on this sequence except when at the beginning/end
:of your history list and the beep will be on the first 'k'/'j'.  So I assume
:you mean lots of 'j's and 'k's until there's a beep (?)

Whoops. This was a dumb thing to say.  Sorry.  It's been a long time since
I've used vi for much more than quick changes to programs.  (Don't you 
sometimes wish there was cancellation for email like there is for news).

::3. 'a' (add) ' ' (any character)  (a '^Q' suddenly appears on the command line)
::4. <CTRL>-'c' (break)
::zsh: 13975 bus error  zsh -f
::On SunOS, after step 4, the shell doesn't crash but instead freezes.
:
:Even then, I couldn't replicate this second part on NetBSD.

I still couldn't replicate this second part on NetBSD.
-- 
Mason [G.C.W]  mason@werple.mira.net.au    "Hurt...Agony...Pain...LOVE-IT"

zsh v 2.6-beta13 bug (fwd)

[mason]

:On:
:  HP-UX A.09.01 A 9000/715
:  IRIX 5.3 IP22 mips
:  SunOS 5.4 sun4d sparc
:In 'bindkey -v' mode, if I do the '~' command on an empty line,
:the cursor moves up to the first cursor of the line before the current
:line.  Instead, nothing should happen.

In viswapmode(), cs was being set to -1 (cs should always be >= 0) - should 
probably put a sanity check for this in zle_refresh.c but it may obscure
other bugs.

:Additionally, on HP, after doing that, I can sometimes crash zsh, if I do:
:1. '~' (as described above)
:2. 'j' 'k' 'j' 'k'... (until there's a beep)

?? You shouldn't get a beep on this sequence except when at the beginning/end
of your history list and the beep will be on the first 'k'/'j'.  So I assume
you mean lots of 'j's and 'k's until there's a beep (?)

:3. 'a' (add) ' ' (any character)  (a '^Q' suddenly appears on the command line)
:4. <CTRL>-'c' (break)
:zsh: 13975 bus error  zsh -f
:On SunOS, after step 4, the shell doesn't crash but instead freezes.

Even then, I couldn't replicate this second part on NetBSD.

Anyway, this should fix up the first problem.  Anyone who knows zle_vi.c
more than me (that's everyone), might want to validate this


*** zle_vi.c.bak	Tue Apr  2 11:42:26 1996
--- zle_vi.c	Tue Apr  2 11:42:26 1996
***************
*** 735,740 ****
--- 735,742 ----
      if (mult < 1)
  	return;
      eol = findeol();
+     if (cs == eol)
+ 	return;			/* empty buffer */
      while (cs < eol && mult--) {
  	if (islower(line[cs]))
  	    line[cs] = tuupper(line[cs]);


-- 
Mason [G.C.W]  mason@werple.mira.net.au    "Hurt...Agony...Pain...LOVE-IT"

Re: zsh v 2.6-beta13 bug (fwd)

[Zefram]

>In viswapmode(), cs was being set to -1 (cs should always be >= 0)

I already fixed that and sent a patch to the list.

>                                                                     should 
>probably put a sanity check for this in zle_refresh.c but it may obscure
>other bugs.

Don't.  The unusual cursor position is a useful clue that something's
broken -- that the cursor has somehow got outside the buffer.  That's
how I found the ~-on-an-empty-line bug: on my Linux box I occasionally
accidentally hit a function key that sent a sequence ^[13~ (not sure of
the number).

On second thoughts, you could put in a sanity check and still have the
current bug highlighting by adding an error message output as well as
putting the cursor within the buffer.  But this would take more extra
code than is likely worthwhile for a `can't happen' condition.

>:Additionally, on HP, after doing that, I can sometimes crash zsh, if I do:
>:1. '~' (as described above)
>:2. 'j' 'k' 'j' 'k'... (until there's a beep)

With the cursor off the end of the buffer, there's undefined behaviour
of a particularly undefined variety.  I'm not surprised it crashes.

-zefram