* Bug in if... then if... parsing
@ 2016-03-06 22:27 Bart Schaefer
2016-03-06 23:05 ` Bart Schaefer
0 siblings, 1 reply; 3+ messages in thread
From: Bart Schaefer @ 2016-03-06 22:27 UTC (permalink / raw)
To: zsh-workers
Reproducible at least as long ago as zsh-4.2.0.
Consider:
torch% x () {
function> if false
function if> then
function then> x=1
function then> elif true
function elif> then
function elif-then> if :
function elif-then if> else
function else> :
function else> fi
function> }
torch%
Here it is without the PS2 prompts:
x () {
if false
then
x=1
elif true
then
if :
else
:
fi
}
This should be a parse error --
torch% if :
if> else
zsh: parse error near `else'
torch%
-- but instead it's accepted, the parser has somehow implied the
"missing" then/fi with a blank line between:
torch% functions -x4 x
x () {
if false
then
x=1
elif true
then
if :
then
fi
else
:
fi
}
torch%
I was at one point able to get the parser into a state where this caused a
correct structure to syntax error because this weird implicit "fi" doubled
an actual "fi", but it was in the context of a larger function and I lost
it from my terminal scrollback by the time I worked out that it wasn't
something I was doing wrong. It had something to do with "then" appearing
with other code on the same line rather than on a line by itself.
As far as I can tell this only happens when "if" immediately follows "then".
At first I thought the "elif" was also required, but no:
torch% if :
if> then
then> if :
then if> else
else> fi
torch%
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Bug in if... then if... parsing
2016-03-06 22:27 Bug in if... then if... parsing Bart Schaefer
@ 2016-03-06 23:05 ` Bart Schaefer
2016-03-07 10:44 ` Peter Stephenson
0 siblings, 1 reply; 3+ messages in thread
From: Bart Schaefer @ 2016-03-06 23:05 UTC (permalink / raw)
To: zsh-workers
On Mar 6, 2:27pm, Bart Schaefer wrote:
}
} As far as I can tell this only happens when "if" immediately follows "then".
The following seems to be the simplest fix. I was afraid this was going
to be a lot harder to track down.
Does anyone recall why par_list() and par_list1() return a value when
literally nothing ever examines that value? What does the 1 or 0 that
is returned even mean?
diff --git a/Src/parse.c b/Src/parse.c
index 628a9aa..349d1e4 100644
--- a/Src/parse.c
+++ b/Src/parse.c
@@ -1413,7 +1413,7 @@ par_if(int *cmplx)
}
}
cmdpop();
- if (xtok == ELSE) {
+ if (xtok == ELSE || tok == ELSE) {
pp = ecadd(0);
cmdpush(CS_ELSE);
while (tok == SEPER)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Bug in if... then if... parsing
2016-03-06 23:05 ` Bart Schaefer
@ 2016-03-07 10:44 ` Peter Stephenson
0 siblings, 0 replies; 3+ messages in thread
From: Peter Stephenson @ 2016-03-07 10:44 UTC (permalink / raw)
To: zsh-workers
On Sun, 06 Mar 2016 15:05:46 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Does anyone recall why par_list() and par_list1() return a value when
> literally nothing ever examines that value? What does the 1 or 0 that
> is returned even mean?
I don't remember the details, but it was somehow related to whether you
were going to need to do more parsing. I think tweaking the upper
levels of the parse hierarchy made it redundant. I did run at into this
at some point last year but didn't simplify it then.
pws
diff --git a/Src/parse.c b/Src/parse.c
index 349d1e4..94ac049 100644
--- a/Src/parse.c
+++ b/Src/parse.c
@@ -718,7 +718,7 @@ set_sublist_code(int p, int type, int flags, int skip, int cmplx)
*/
/**/
-static int
+static void
par_list(int *cmplx)
{
int p, lp = -1, c;
@@ -747,19 +747,15 @@ par_list(int *cmplx)
goto rec;
} else
set_list_code(p, (Z_SYNC | Z_END), c);
- return 1;
} else {
ecused--;
- if (lp >= 0) {
+ if (lp >= 0)
ecbuf[lp] |= wc_bdata(Z_END);
- return 1;
- }
- return 0;
}
}
/**/
-static int
+static void
par_list1(int *cmplx)
{
int p = ecadd(0), c = 0;
@@ -767,11 +763,8 @@ par_list1(int *cmplx)
if (par_sublist(&c)) {
set_list_code(p, (Z_SYNC | Z_END), c);
*cmplx |= c;
- return 1;
- } else {
+ } else
ecused--;
- return 0;
- }
}
/*
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-03-07 10:44 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-06 22:27 Bug in if... then if... parsing Bart Schaefer
2016-03-06 23:05 ` Bart Schaefer
2016-03-07 10:44 ` Peter Stephenson
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).