Re: Certain pattern causing shell to crash

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Fri, 7 Jan 2011 15:35:07 -0500
Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx> wrote:
> On 2011-01-06 at 19:54 +0000, Peter Stephenson wrote:
> > On Thu, 6 Jan 2011 13:51:35 -0500
> > Ricky Zhou <ricky@xxxxxxxxx> wrote:
> > > For what it's worth, I did a git bisect, and the segfault was introduced
> > > in d234059b1c6493e5eefb6c28aa2b8a021d894d51.  Hopefully this can be of
> > > use to somebody more familiar with how this code works.
> > 
> > (Ah, so I need to use
> > 
> > git diff d234059b1c6493e5eefb6c28aa2b8a021d894d51^\!
> > 
> > to look at it.  Obvious.)
> > 
> > Yes, that narrows it down a lot, thanks.
> 
> Oh dear, it was me fixing another problem?  I'm sorry.
> 
> So in that change, I was avoiding shoving junk into the parse tree; was
> that junk protecting us somehow?   Did my original =~ feature manage
> to introduce parallel code/decode bugs and the =~ code bug-fix exposed
> the decode bug?

I think what happened is that = and =~ were originally implemented
similarly, then you discovered that wasn't appropriate, but missed one
of the consequences.  It's inevitable that changing the way the wordcode
is structured changes how you need to decode it to turn it back into
text, but actually keeping the two consistent is a bit obscure, so this
isn't the first time this has happened.  The code in text.c is consequent
on what happens elsewhere, not the other way round, so this latest bug
doesn't imply any major structural problem.

-- 
Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/