Re: zsh 4.3.4 released

Re: zsh 4.3.4 released

[Peter Stephenson]

(I've moved this to zsh-workers.)

"Mikael Magnusson" wrote:
> Here it is with debug symbols,

Thanks.  The crash is when outputting whitespace just before the "esac"
of a case statement.  I stepped through it and I couldn't see an obvious
problem.

It might be locale dependent; what are your settings?  Does exporting
a different value for LC_ALL make a difference?

Could you have a look at the values of the variables
tptr, tbuf, tlim, tsiz, tindent, tnewlins at the point of the crash?
(They're all file static in text.c, where it crashed.)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview

Re: zsh 4.3.4 released

[Peter Stephenson]

(Moved to zsh-workers.)

"Christoph Bauer" wrote:
> Two short remarks:
>   - HP-UX 11: I need to define _INCLUDE__STDC_A1_SOURCE to compile zsh
>     with HP's cc.
>     (set CFLAGS=3D"$OTHER_CFLAGS -D_INCLUDE__STDC_A1_SOURCE")

Thanks for the report.  Is there anyway we can tell that this needs
defining?

>   - on SGI zsh-4.3.4 crashes immediatly:
> Starting program: /projekte/backup/tools/unix/sgi6n3/bin/zsh-4.3.4=20
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x1005b328 in optlookup ()
> (gdb) where
> #0  0x1005b328 in optlookup ()
> #1  0x1005b0c4 in bin_setopt ()
> #2  0x1000e8f8 in execbuiltin ()
> #3  0x1000e8f8 in execbuiltin ()
> Previous frame identical to this frame (corrupt stack?)

I don't have an SGI around and there isn't any suspicious-looking code
in optlookup() (though it has recently changed).  Are you able to
compile with --enable-zsh-debug and see what "name" is being passed to
the last frame ("show name")?  Alternatively, can you see which "setopt"
statement is causing the problem, or does it happen with a lot of
different varieties of statement?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview

Re: zsh 4.3.4 released

[Mikael Magnusson]

On 23/04/07, Peter Stephenson <pws@csr.com> wrote:
> (I've moved this to zsh-workers.)
>
> "Mikael Magnusson" wrote:
> > Here it is with debug symbols,
>
> Thanks.  The crash is when outputting whitespace just before the "esac"
> of a case statement.  I stepped through it and I couldn't see an obvious
> problem.
>
> It might be locale dependent; what are your settings?  Does exporting
> a different value for LC_ALL make a difference?
>
> Could you have a look at the values of the variables
> tptr, tbuf, tlim, tsiz, tindent, tnewlins at the point of the crash?
> (They're all file static in text.c, where it crashed.)

Got the same result with LC_ALL=C and LC_ALL=en_US.

0x080d0ce4 in taddchr (c=9) at text.c:42
42	    *tptr++ = c;
(gdb) print tptr
$8 = 0x2000000 <Address 0x2000000 out of bounds>
(gdb) print tbuf
$9 = 0x0
(gdb) print tlim
$10 = 0x4000000 <Address 0x4000000 out of bounds>
(gdb) print tsiz
$11 = 67108864
(gdb) print tindent
$12 = -2
(gdb) print tnewlins
$13 = 1


-- 
Mikael Magnusson

Re: zsh 4.3.4 released

[Peter Stephenson]

"Mikael Magnusson" wrote:
> (gdb) print tindent
> $12 = -2

Thanks.  This is the problem; tindent should never be less than zero.
I'm not sure why I'm not seeing it; it might suggest the structure with
the function in it is already corrupt at the point where you run
"which".

The following patch should stop the crash (so it's probably worth
having) and report at the point where it first becomes confused, though
it doesn't address the underlying problem.

Is it possibly you have old wordcode for the dot file that might define
svmode?  (Obviously the shell should be robust even if this is the case;
since the wordcode has a version stamp this shouldn't happen with a
released version of the shell.)

Index: Src/text.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/text.c,v
retrieving revision 1.18
diff -u -r1.18 text.c
--- Src/text.c	19 Jan 2007 21:36:03 -0000	1.18
+++ Src/text.c	23 Apr 2007 14:50:00 -0000
@@ -33,6 +33,14 @@
 static char *tptr, *tbuf, *tlim;
 static int tsiz, tindent, tnewlins, tjob;
 
+static void
+dec_tindent(void)
+{
+    DPUTS(tindent == 0, "attempting to decrement tindent below zero");
+    if (tindent > 0)
+	tindent--;
+}
+
 /* add a character to the text buffer */
 
 /**/
@@ -354,7 +362,7 @@
 		state->pc++;
 	    } else {
 		state->pc = s->u._subsh.end;
-		tindent--;
+		dec_tindent();
 		taddnl();
 		taddstr(")");
 		stack = 1;
@@ -371,7 +379,7 @@
 		state->pc++;
 	    } else {
 		state->pc = s->u._subsh.end;
-		tindent--;
+		dec_tindent();
 		taddnl();
 		taddstr("}");
 		stack = 1;
@@ -387,7 +395,7 @@
 		} else
 		    stack = 1;
 	    } else {
-		tindent--;
+		dec_tindent();
 		stack = 1;
 	    }
 	    break;
@@ -414,7 +422,7 @@
 	    } else {
 		state->strs = s->u._funcdef.strs;
 		state->pc = s->u._funcdef.end;
-		tindent--;
+		dec_tindent();
 		taddnl();
 		taddstr("}");
 		stack = 1;
@@ -444,7 +452,7 @@
 		taddnl();
 		tpush(code, 1);
 	    } else {
-		tindent--;
+		dec_tindent();
 		taddnl();
 		taddstr("done");
 		stack = 1;
@@ -462,7 +470,7 @@
 		taddnl();
 		tpush(code, 1);
 	    } else {
-		tindent--;
+		dec_tindent();
 		taddnl();
 		taddstr("done");
 		stack = 1;
@@ -475,14 +483,14 @@
 		tindent++;
 		tpush(code, 0);
 	    } else if (!s->pop) {
-		tindent--;
+		dec_tindent();
 		taddnl();
 		taddstr("do");
 		tindent++;
 		taddnl();
 		s->pop = 1;
 	    } else {
-		tindent--;
+		dec_tindent();
 		taddnl();
 		taddstr("done");
 		stack = 1;
@@ -498,7 +506,7 @@
 		taddnl();
 		tpush(code, 1);
 	    } else {
-		tindent--;
+		dec_tindent();
 		taddnl();
 		taddstr("done");
 		stack = 1;
@@ -536,7 +544,7 @@
 		    n->pop = (state->pc - 2 + WC_CASE_SKIP(code) >= end);
 		}
 	    } else if (state->pc < s->u._case.end) {
-		tindent--;
+		dec_tindent();
 		switch (WC_CASE_TYPE(code)) {
 		case WC_CASE_OR:
 		    taddstr(" ;;");
@@ -564,7 +572,7 @@
 		s->pop = ((state->pc - 2 + WC_CASE_SKIP(code)) >=
 			  s->u._case.end);
 	    } else {
-		tindent--;
+		dec_tindent();
 		switch (WC_CASE_TYPE(code)) {
 		case WC_CASE_OR:
 		    taddstr(" ;;");
@@ -578,7 +586,7 @@
 		    taddstr(";|");
 		    break;
 		}
-		tindent--;
+		dec_tindent();
 		if (tnewlins)
 		    taddnl();
 		else
@@ -601,14 +609,14 @@
 	    } else if (s->pop) {
 		stack = 1;
 	    } else if (s->u._if.cond) {
-		tindent--;
+		dec_tindent();
 		taddnl();
 		taddstr("then");
 		tindent++;
 		taddnl();
 		s->u._if.cond = 0;
 	    } else if (state->pc < s->u._if.end) {
-		tindent--;
+		dec_tindent();
 		taddnl();
 		code = *state->pc++;
 		if (WC_IF_TYPE(code) == WC_IF_ELIF) {
@@ -622,7 +630,7 @@
 		}
 	    } else {
 		s->pop = 1;
-		tindent--;
+		dec_tindent();
 		taddnl();
 		taddstr("fi");
 		stack = 1;
@@ -760,14 +768,14 @@
 		n->u._subsh.end = state->pc + WC_CURSH_SKIP(state->pc[-1]);
 	    } else if (!s->pop) {
 		state->pc = s->u._subsh.end;
-		tindent--;
+		dec_tindent();
 		taddnl();
 		taddstr("} always {");
 		tindent++;
 		taddnl();
 		s->pop = 1;
 	    } else {
-		tindent--;
+		dec_tindent();
 		taddnl();
 		taddstr("}");
 		stack = 1;


-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview

Re: zsh 4.3.4 released

[Peter Stephenson]

"Christoph Bauer" <Christoph.Bauer@lmsintl.com> wrote:
> Hi,
> 
> HP-UX: 
> 
> _INCLUDE__STDC_A1_SOURCE has to be defined before including <wchar.h>.
> I think gcc defines _INCLUDE__STDC_A1_SOURCE anyway. Thus I suggest
> these changes:

Thanks, I've committed this.

> SGI:
>
> $ setopt a
> 
> crashes zsh

Hm.  That doesn't look a problem we've seen anywhere else.  It looks like
something basic, e.g. a bad library linked in or we've grossly messed up
some allocation and for some reason it's never triggered elsewhere.  It
doesn't look very easy to debug by email.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview

Re: zsh 4.3.4 released

[Mikael Magnusson]

On 23/04/07, Peter Stephenson <pws@csr.com> wrote:
> "Mikael Magnusson" wrote:
> > (gdb) print tindent
> > $12 = -2
>
> Thanks.  This is the problem; tindent should never be less than zero.
> I'm not sure why I'm not seeing it; it might suggest the structure with
> the function in it is already corrupt at the point where you run
> "which".
>
> The following patch should stop the crash (so it's probably worth
> having) and report at the point where it first becomes confused, though
> it doesn't address the underlying problem.
>
> Is it possibly you have old wordcode for the dot file that might define
> svmode?  (Obviously the shell should be robust even if this is the case;
> since the wordcode has a version stamp this shouldn't happen with a
> released version of the shell.)

Aha, this seems to have been the problem. I renamed my .zshurxvt.zwc
and it doesn't crash anymore. I always run zrecompile -p on all my .z*
files after upgrading zsh but apparently it only takes effect if the
.file is newer than the .file.zwc, maybe it should also take effect if
$SHELL is newer than the .zwc?

-- 
Mikael Magnusson

Re: zsh 4.3.4 released

[Mikael Magnusson]

On 23/04/07, Peter Stephenson <pws@csr.com> wrote:
> "Mikael Magnusson" wrote:
> > (gdb) print tindent
> > $12 = -2
>
> Thanks.  This is the problem; tindent should never be less than zero.
> I'm not sure why I'm not seeing it; it might suggest the structure with
> the function in it is already corrupt at the point where you run
> "which".
>
> The following patch should stop the crash (so it's probably worth
> having) and report at the point where it first becomes confused, though
> it doesn't address the underlying problem.

With latest cvs, it still crashes, but differently.

Program received signal SIGSEGV, Segmentation fault.
0xa7dc90cc in memcpy () from /lib/libc.so.6
(gdb) bt
#0  0xa7dc90cc in memcpy () from /lib/libc.so.6
#1  0x080d0e1b in taddstr (s=0x80e4c4a "esac") at text.c:81
#2  0x080d1e19 in gettext2 (state=0xaf8659c0) at text.c:594
#3  0x080d0f9e in getpermtext (prog=0x8115538, c=0x8116a64) at text.c:141
#4  0x08081057 in printshfuncnode (hn=0x8115560, printflags=32) at
hashtable.c:889
#5  0x080619f7 in bin_whence (nam=0xa7f362a0 "which", argv=0xaf865c50,
ops=0xaf865ca0, func=0)
    at builtin.c:3050
#6  0x080536bd in execbuiltin (args=0xa7f36278, bn=0x80e73a8) at builtin.c:438
#7  0x0807496c in execcmd (state=0xaf866080, input=0, output=0,
how=18, last1=2) at exec.c:2670
#8  0x08070cd1 in execpline2 (state=0xaf866080, pcode=195, how=18,
input=0, output=0, last1=0)
    at exec.c:1343
#9  0x0806fc28 in execpline (state=0xaf866080, slcode=4098, how=18,
last1=0) at exec.c:1129
#10 0x0806f355 in execlist (state=0xaf866080, dont_change_job=0,
exiting=0) at exec.c:935
#11 0x0806ef63 in execode (p=0xa7f36220, dont_change_job=0, exiting=0)
at exec.c:793
#12 0x0808996c in loop (toplevel=1, justonce=0) at init.c:180
#13 0x0808c470 in zsh_main (argc=2, argv=0xaf8661b4) at init.c:1347
#14 0x08052d12 in main (argc=2, argv=0xaf8661b4) at ./main.c:93
(gdb) frame 1
#1  0x080d0e1b in taddstr (s=0x80e4c4a "esac") at text.c:81
81		memcpy(tptr, s, sl);
(gdb) print tptr
$1 = 0x1ffffff <Address 0x1ffffff out of bounds>
(gdb) print s
$2 = 0x80e4c4a "esac"
(gdb) print sl
$3 = 4
(gdb) print tbuf
$4 = 0x0
(gdb) print tlim
$5 = 0x4000000 <Address 0x4000000 out of bounds>
(gdb) print tsiz
$6 = 67108864
(gdb) print tindent
$7 = 0
(gdb) print tnewlins
$8 = 1

Don't know if it would help but here's the zwc file too,
http://mikachu.ath.cx/dot-zshurxvt.zwc

-- 
Mikael Magnusson

Re: zsh 4.3.4 released

[Peter Stephenson]

"Mikael Magnusson" <mikachu@gmail.com> wrote:
> > Is it possibly you have old wordcode for the dot file that might define
> > svmode?  (Obviously the shell should be robust even if this is the case;
> > since the wordcode has a version stamp this shouldn't happen with a
> > released version of the shell.)
> 
> Aha, this seems to have been the problem. I renamed my .zshurxvt.zwc
> and it doesn't crash anymore. I always run zrecompile -p on all my .z*
> files after upgrading zsh but apparently it only takes effect if the
> .file is newer than the .file.zwc, maybe it should also take effect if
> $SHELL is newer than the .zwc?

I think I've found the problem: parse.c doesn't get recompiled when
version.h changes, so zcompile might output the wrong version, so the shell
can't check properly when the ZWC file is loaded.

Luckily, this won't happen if the shell is built from scratch, so it
doesn't affect the fast majority of installed versions.

I think the fix is as simple as changing the dependency, though I decided I
felt happier if the header for the ZWC file had uninitialised bits set to
null bytes rather than (say) the password that was lying around in
memory.

Thanks for your help.

Index: Src/parse.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/parse.c,v
retrieving revision 1.60
diff -u -r1.60 parse.c
--- Src/parse.c	19 Jan 2007 21:36:03 -0000	1.60
+++ Src/parse.c	23 Apr 2007 16:36:30 -0000
@@ -2693,6 +2693,8 @@
     if (map == 1)
 	map = (tlen >= FD_MINMAP);
 
+    memset(pre, 0, sizeof(wordcode) * FD_PRELEN)
+
     for (ohlen = hlen; ; hlen = ohlen) {
 	fdmagic(pre) = (other ? FD_OMAGIC : FD_MAGIC);
 	fdsetflags(pre, ((map ? FDF_MAP : 0) | other));
Index: Src/zsh.mdd
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/zsh.mdd,v
retrieving revision 1.15
diff -u -r1.15 zsh.mdd
--- Src/zsh.mdd	21 Jan 2007 22:47:41 -0000	1.15
+++ Src/zsh.mdd	23 Apr 2007 16:36:30 -0000
@@ -31,7 +31,7 @@
 
 init.o: bltinmods.list zshpaths.h zshxmods.h
 
-init.o params.o: version.h
+init.o params.o parse.o: version.h
 
 version.h: $(sdir_top)/Config/version.mk
 	echo '#define ZSH_VERSION "'$(VERSION)'"' > $@


-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview

Re: zsh 4.3.4 released

[Peter Stephenson]

Peter Stephenson <pws@csr.com> wrote:
> I think I've found the problem: parse.c doesn't get recompiled when
> version.h changes, so zcompile might output the wrong version, so the shell
> can't check properly when the ZWC file is loaded.

Errm... and, in fact, it doesn't even when it can.  And if it did, and
error checking was on, the error message would be wrong.  Presumably this
has always been broken.

Index: Src/parse.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/parse.c,v
retrieving revision 1.62
diff -u -r1.62 parse.c
--- Src/parse.c	23 Apr 2007 16:55:00 -0000	1.62
+++ Src/parse.c	23 Apr 2007 17:04:02 -0000
@@ -2617,9 +2617,10 @@
     }
     if (read(fd, buf, (FD_PRELEN + 1) * sizeof(wordcode)) !=
 	((FD_PRELEN + 1) * sizeof(wordcode)) ||
-	(v = (fdmagic(buf) != FD_MAGIC && fdmagic(buf) != FD_OMAGIC))) {
+	(v = (fdmagic(buf) != FD_MAGIC && fdmagic(buf) != FD_OMAGIC)) ||
+	strcmp(fdversion(buf), ZSH_VERSION)) {
 	if (err) {
-	    if (v) {
+	    if (!v) {
 		zwarnnam(nam, "zwc file has wrong version (zsh-%s): %s",
 			 fdversion(buf), name);
 	    } else

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview

Re: zsh 4.3.4 released

[Mikael Magnusson]

On 23/04/07, Peter Stephenson <pws@csr.com> wrote:
> "Mikael Magnusson" <mikachu@gmail.com> wrote:
> > > Is it possibly you have old wordcode for the dot file that might define
> > > svmode?  (Obviously the shell should be robust even if this is the case;
> > > since the wordcode has a version stamp this shouldn't happen with a
> > > released version of the shell.)
> >
> > Aha, this seems to have been the problem. I renamed my .zshurxvt.zwc
> > and it doesn't crash anymore. I always run zrecompile -p on all my .z*
> > files after upgrading zsh but apparently it only takes effect if the
> > .file is newer than the .file.zwc, maybe it should also take effect if
> > $SHELL is newer than the .zwc?
>
> I think I've found the problem: parse.c doesn't get recompiled when
> version.h changes, so zcompile might output the wrong version, so the shell
> can't check properly when the ZWC file is loaded.
>
> Luckily, this won't happen if the shell is built from scratch, so it
> doesn't affect the fast majority of installed versions.
>
> I think the fix is as simple as changing the dependency, though I decided I
> felt happier if the header for the ZWC file had uninitialised bits set to
> null bytes rather than (say) the password that was lying around in
> memory.
>
> Thanks for your help.

No problem, and thank you too.

zrecompile:zcompile:1: zwc file has wrong version (zsh-4.3.2-dev-1):
/root/.zshrc.zwc
re-compiling /root/.zshrc.zwc: succeeded
zrecompile:zcompile:1: zwc file has wrong version (zsh-4.2.0-dev-1):
/root/.zlogout.zwc
re-compiling /root/.zlogout.zwc: succeeded
zrecompile:zcompile:1: zwc file has wrong version (zsh-4.3.3):
/root/.zcompdump.zwc
re-compiling /root/.zcompdump.zwc: succeeded
zrecompile:zcompile:1: zwc file has wrong version (zsh-4.3.3): /etc/profile.zwc
re-compiling /etc/profile.zwc: succeeded
zrecompile:zcompile:1: zwc file has wrong version (zsh-4.3.2-dev-1):
/etc/zprofile.zwc
re-compiling /etc/zprofile.zwc: succeeded
zrecompile:zcompile:1: zwc file has wrong version (zsh-4.3.2-dev-1):
/usr/local/share/zsh/site-functions.zwc
re-compiling /usr/local/share/zsh/site-functions.zwc: succeeded
zrecompile:zcompile:1: zwc file has wrong version (zsh-4.3.2-dev-1):
/home/mikaelh/.zshrc.zwc
re-compiling /home/mikaelh/.zshrc.zwc: succeeded
zrecompile:zcompile:1: zwc file has wrong version (zsh-4.3.3):
/home/mikaelh/.zshenv.zwc
re-compiling /home/mikaelh/.zshenv.zwc: succeeded
zrecompile:zcompile:1: zwc file has wrong version (zsh-4.3.3):
/home/mikaelh/.zcompdump.zwc
re-compiling /home/mikaelh/.zcompdump.zwc: succeeded
zrecompile:zcompile:1: zwc file has wrong version (zsh-4.2.0-dev-1):
/home/mikaelh/.zlogin.zwc
re-compiling /home/mikaelh/.zlogin.zwc: succeeded
zrecompile:zcompile:1: zwc file has wrong version (zsh-4.2.0-dev-1):
/home/mikaelh/.zlogout.zwc
re-compiling /home/mikaelh/.zlogout.zwc: succeeded
zrecompile:zcompile:1: zwc file has wrong version (zsh-4.3.2-dev-1):
/home/mikaelh/.delete-to.zwc
re-compiling /home/mikaelh/.delete-to.zwc: succeeded
zrecompile:zcompile:1: zwc file has wrong version (zsh-4.3.0-dev-1):
/home/mikaelh/.zshurxvt.zwc
re-compiling /home/mikaelh/.zshurxvt.zwc: succeeded

:)

-- 
Mikael Magnusson

Re: zsh 4.3.4 released

[Paul Ackersviller]

On Thu, Apr 19, 2007 at 12:07:58PM +0100, Peter Stephenson wrote:
> 	* unposted: Functions/Misc/add-zsh-hook: should have been
> 	added ages ago but wasn't.

I've encountered a wee problem with this, and I do mean wee -- the time it
took me to spot this proves my font is too small for my powers of vision.

$ zsh-4.3.4-dev-0 -f
% zcompile -z share/zsh/4.3.4-dev-0/functions/add-zsh-hook
zsh: parse error near `else'
zcompile: can't read file: share/zsh/4.3.4-dev-0/functions/add-zsh-hook

This fixes it:

--- Functions/Misc/add-zsh-hook 19 Apr 2007 09:40:56 -0000      1.1
+++ Functions/Misc/add-zsh-hook 19 Apr 2007 19:24:23 -0000
@@ -52,7 +52,7 @@
     (( ${(P)#hook} )) || unset $hook
   fi
 else
-  if (( ${(P)+hook} )): then
+  if (( ${(P)+hook} )); then
     if (( ${(P)hook[(I)$fn]} == 0 )); then
       set -A $hook ${(P)hook} $fn
     fi