Re: completion matching problem with 4.3.8

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Thu, 30 Oct 2008 16:43:40 +0100
Oliver Kiddle <okiddle@xxxxxxxxxxx> wrote:
> Anyway, the gcc built zsh also has the problem so it isn't compiler
> related. I tried running the minimal zsh -f, compctl test on Linux
> through valgrind and I get the following message. Maybe valgrind has
> found the source of the problem:
>...
> Valgrind also finds some leaked memory from parse_class (complete.c:467)
> with the same test.

This should keep valgrind happy.  I can't see any way these changes can
be wrong, but I've said that before.

Unfortunately, when I do this, the original problem (showing too many
characters in an ambiguous completion) now crops up.  This will take
*massively* more time to fix than the hour and a half I've spent so far.

Index: Src/Zle/complete.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complete.c,v
retrieving revision 1.42
diff -u -r1.42 complete.c
--- Src/Zle/complete.c	23 Sep 2008 19:33:26 -0000	1.42
+++ Src/Zle/complete.c	30 Oct 2008 20:14:21 -0000
@@ -464,7 +464,7 @@
      * As the input string is metafied, but shouldn't contain shell
      * tokens, we can just add our own tokens willy nilly.
      */
-    optr = p->u.str = zalloc((optr-iptr) + 1);
+    optr = p->u.str = zhalloc((optr-iptr) + 1);
 
     while (firsttime || *iptr != endchar) {
 	int ch;
Index: Src/Zle/compmatch.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compmatch.c,v
retrieving revision 1.59
diff -u -r1.59 compmatch.c
--- Src/Zle/compmatch.c	12 Oct 2008 19:28:10 -0000	1.59
+++ Src/Zle/compmatch.c	30 Oct 2008 20:14:22 -0000
@@ -1687,6 +1687,7 @@
     llen = mp->llen;
     rl = 0;
 
+    *line = '\0';
     if (sfx)
     {
 	/*


-- 
Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/