Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: .zsh_history bugreport
- X-seq: zsh-workers 16183
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Wayne Davison <wayned@xxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: .zsh_history bugreport
- Date: Fri, 26 Oct 2001 15:51:03 -0700
- Cc: zsh-workers@xxxxxxxxxx
- In-reply-to: <Pine.LNX.4.21.0110261110100.7802-100000@xxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <Pine.LNX.4.21.0110261110100.7802-100000@xxxxxxxxxxxxxx>
On Oct 26, 11:26am, Wayne Davison wrote:
> Subject: Re: .zsh_history bugreport
> On Fri, 26 Oct 2001, Bart Schaefer wrote:
> > This was fixed by the patch in users/4269 and should be working in the
> > zsh-4.0.4 release from earlier today.
>
> Hmm. The start >= l (ell) check can only error-out if the null byte
> is at the start of the line (since once a section gets measured, it
> can't ever get any shorter).
No, that's not true. Look at the recursive call. The value passed in
for start is the value of the previous l. So if fgets() returns nonzero
but buf didn't get any longer, start == l and (start >= l) is true and so
we return -1. The greater-than check is just in there for completeness;
only the equivalence should happen in practice.
It doesn't matter where the null byte is.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author