Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [PATCH 0/3] jp: Patchset for parameter expansion segfaults
- X-seq: zsh-workers 42281
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: "zsh-workers@xxxxxxx" <zsh-workers@xxxxxxx>
- Subject: Re: [PATCH 0/3] jp: Patchset for parameter expansion segfaults
- Date: Sun, 14 Jan 2018 12:41:05 -0800
- Cc: dana <dana@xxxxxxx>, Joey Pabalinas <joeypabalinas@xxxxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RbMwCVYU/gH15odAl0NMvXljsf7Rq3I0f2LddLZ0QW8=; b=LHpF4Bu4PH/jXFDqij3xrwRA9orvo9WFW1fACTstXP4paGjJfp8wfGbK7VylttWotx AGyAoWX7BB6a5wBYtX6vbFSRWJbSsL4yS30gJjj1mIvUpTi4KuibfKlCp57tt0idQSgm /EgXTeyLCm60MSRbviMvDEt6NVTRNAXbNUj8ZuA6hmXT1RGDo90A7Bl4BPsyGgAghjJj 5TubKUqqM4OB3Hu8rxqgPQifpDm8x7A0QzQb/jC+cXkyeogNnO6LNRpLtvSL8zgCw7ac Ubwe9I5fel43eN0R20xIHVz6AY2yt9GUDF/vfYmTF7MkQeKQLqZqoVjGB7S5ooSSC543 BsiA==
- In-reply-to: <20180114152344.12018-1-joeypabalinas@gmail.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20180114152344.12018-1-joeypabalinas@gmail.com>
On Sun, Jan 14, 2018 at 7:23 AM, Joey Pabalinas <joeypabalinas@xxxxxxxxx> wrote:
>
> Joey Pabalinas (3):
> - Fix segfaults during parameter expansion
> - Use `(nil)` for empty identifier strings
> - Add `dupstring()` fallback to `zhtricat()`
With appreciation for your efforts here, preventing segfaults is not
the correct goal. The goal should be that the software produces the
correct results.
Trapping bad pointers in the string copy/catenate routines potentially
masks more serious errors; it introduces what only appears to be
error-free operation in cases that probably ought to fail. A segfault
in zhtricat() is nearly always an indication that the calling code is
doing something wrong, and covering that up only makes it harder to
find what that is.
At the very least any such "succeed in spite of caller screwup" code
should be wrapped in #ifndef DEBUG or the like.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author