Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Bug in if... then if... parsing
On Sun, 06 Mar 2016 15:05:46 -0800
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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;
- }
}
/*
Messages sorted by:
Reverse Date,
Date,
Thread,
Author