Re: PATCH: Crash bug on garbage input (previously reported to Debian)

[Peter Stephenson <p.stephenson@samsung.com>]

On Sun, 15 Feb 2015 11:26:22 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> torch% ${($((()$[(s:    
> braceparam mathsubst mathsubst> this ends up in the history)}})))}
> Attempt to inungetc() at start of input.
> zsh: Garbled input at \n (binary file as commands?)
> zsh: parse error near `)'

I see basically what's happening.  Here's the simplest form --- and note
that actually this isn't garbled input at all.

% print $((echo foo
mathsubst> ); echo bar)
Attempt to inungetc() at start of input.
zsh: Garbled input at \n (binary file as commands?)
zsh: parse error near `)'

We try to parse this as arithmetic, but we find out it isn't --- and we
only find this out in the continuation line.  Normally, when reading
continuation lines we just forget the old line from the input, so we
can't back up over it.  Here, however, we need to back up to be able to
parse again as a command string.  The code for the lexer assumes we can
do this but down below in the raw input layer we can't.

It looks like we do allow newlines as whitespace in arithmetic, so I
think we do need to allow the back up.  That implies we somehow need to
detect we're doing the tentative looking for math mode and if so add the
new line as a continuation of the old one --- that's allowed by the
input mechanism and I don't see why that wouldn't work here (largely
because I haven't tried it yet).  So it "only" remains working out where
to detect this.

This will need a test, too.

pws