From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-16274-mason-zsh=primenet.com.au@sunsite.dk>
Received: (qmail 25056 invoked from network); 22 Nov 2001 08:24:58 -0000
Received: from sunsite.dk (130.225.247.90)
  by ns1.primenet.com.au with SMTP; 22 Nov 2001 08:24:58 -0000
Received: (qmail 6892 invoked by alias); 22 Nov 2001 08:24:44 -0000
Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 16274
Received: (qmail 6879 invoked from network); 22 Nov 2001 08:24:42 -0000
Message-Id: <7D865FB0D0A1D5118B6E000347055BBB14848B@G9JNT.mgb01.telekom.de>
From: "Wischnowsky, Sven" <Sven.Wischnowsky@t-systems.de>
To: zsh-workers@sunsite.dk
Subject: Re: [bug report] 4.0.2 / 4.0.4 dumps core
Date: Thu, 22 Nov 2001 09:09:22 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain


Bart wrote:

> I'm wondering if it wouldn't be more appropriate to duplicate 
> the strings
> in compctl.c:dumphashtable() rather than simply allowing the 
> completion
> code to poke bytes into the real reswdtab.

Yes, I thought about doing that, too, and I don't really care where
we put that ztrdup().

But it isn't the completion code. At least not for me. It SEGVed in
the pattern matching code (called from the completion code).

And I was tempted to change that code to at least test if it was
trying to write a '\0' onto the Null-byte at the end of a string.


Bye
  Sven