Re: [PATCH] Fix a logic bug in _zle

[Lawrence Velázquez <larryv@xxxxxxx>]

On Tue, Jun 1, 2021, at 4:53 AM, Marlon Richert wrote:
> On Tue, Jun 1, 2021 at 12:56 AM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> >
> > On Mon, May 31, 2021 at 10:49 AM Marlon Richert
> > <marlon.richert@xxxxxxxxx> wrote:
> > >
> > > On Mon, May 31, 2021 at 8:08 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > > >
> > > > For purposes of the commit log, we should be told what this means in
> > > > terms of a behavior change.
> > >
> > > Is it good enough this way?
> >
> > Better, but you could have just said that in the email text rather
> > than embed it in the patch file.
> 
> Ah, OK. I thought you meant I should include it in the patch itself.
> 
> > However, I can't figure out when $state[1] == widget-function is ever
> > true.  Did you possibly mean widget-or-function ?  If not, can you
> > give an example?
> 
> Sorry, typo. Yes, I meant widget-or-function. But actually, I realize
> now that I made further mistakes in my explanation yesterday evening.
> I'll try to explain better.
> 
> What happens in the unpatched _zle code is this:
> * On line 54, `;&` causes the (widget*) case to always proceed to the
> (function) case.
> * On line 56, `[[ $state[1] != *function ]] ||` checks to see whether
> the flow should actually continue from (widget*) to (function).
> * However,
>   * when `[[ $state[1] != *function ]]` is true,
>   * then we correctly skip the _wanted call on lines 57-58,
>   * but because the _wanted call is followed by `&& ret=0`
>   * and because || and && have equal precedence and are left associative,
>   * then we incorrectly do `ret=0`,
> 
> So, to correctly summarize the bug: When $state[1] == widget, _zle
> always returns 0, instead of returning 0 for success and non-zero for
> failure. The patch fixes this. If you could update the commit message
> accordingly, that would be great.

ping for further feedback on or committing of 48969

-- 
vq