Re: Bug in if... then if... parsing

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

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;
-    }
 }
 
 /*