Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [bug report] 4.0.2 / 4.0.4 dumps core
- X-seq: zsh-workers 16279
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: "Wischnowsky, Sven" <Sven.Wischnowsky@xxxxxxxxxxxx>, zsh-workers@xxxxxxxxxx
- Subject: Re: [bug report] 4.0.2 / 4.0.4 dumps core
- Date: Thu, 22 Nov 2001 17:56:43 +0000
- In-reply-to: <7D865FB0D0A1D5118B6E000347055BBB14848B@xxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <7D865FB0D0A1D5118B6E000347055BBB14848B@xxxxxxxxxxxxxxxxxxxxxx>
On Nov 22, 9:09am, Wischnowsky, Sven wrote:
}
} Bart wrote:
}
} > I'm wondering if it wouldn't be more appropriate to duplicate the
} > strings in compctl.c:dumphashtable()
}
} Yes, I thought about doing that, too, and I don't really care where
} we put that ztrdup().
It's a matter of the principle that code that's only examining the
contents of a data structure shouldn't be changing those contents, even
if it restores them afterwards.
} > rather than simply allowing the completion code to poke bytes into
} > the real reswdtab.
}
} But it isn't the completion code. At least not for me. It SEGVed in
} the pattern matching code (called from the completion code).
Yes, but it's the completion code that's "violating" the pattern match
code API, in the sense that the pattern match code is supposed to get
writable strings and the completion code isn't providing them.
} 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.
That would unnecessarily penalize every other caller of the pattern
match code, wouldn't it?
If there's no problem with using dupstring() in dumphashtable(), then
I'd prefer to commit my patch rather than yours.
--
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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author