From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-38111-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 18313 invoked by alias); 7 Mar 2016 10:44:20 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 38111
Received: (qmail 26968 invoked from network); 7 Mar 2016 10:44:19 -0000
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.1
X-AuditID: cbfec7f5-f79b16d000005389-e3-56dd5b80804e
Date: Mon, 07 Mar 2016 10:44:12 +0000
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-workers@zsh.org
Subject: Re: Bug in if... then if... parsing
Message-id: <20160307104412.25182548@pwslap01u.europe.root.pri>
In-reply-to: <160306150547.ZM17307@torch.brasslantern.com>
References: <160306142731.ZM3208@torch.brasslantern.com>
 <160306150547.ZM17307@torch.brasslantern.com>
Organization: Samsung Cambridge Solution Centre
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu)
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Brightmail-Tracker:
 H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsVy+t/xy7oN0XfDDGYd5bU42PyQyYHRY9XB
	D0wBjFFcNimpOZllqUX6dglcGdseXGUt6OGuuP57CmMD40SOLkZODgkBE4mjlxawQdhiEhfu
	rQezhQSWMkr8OF3YxcgFZM9gkph+egMTROI0o8TmKY4QiTOMEs0TbrCDJFgEVCX+3FsPZrMJ
	GEpM3TSbEcQWERCXOLv2PAuILSygI/HvVz/YIF4Be4mpe78AbePg4BSwkjh5JRVifobEtNPz
	wcbwC+hLXP37iQniOHuJmVfOMEK0Ckr8mHwPbCSzgJbE5m1NrBC2vMTmNW+ZIeaoS9y4u5t9
	AqPwLCQts5C0zELSsoCReRWjaGppckFxUnqukV5xYm5xaV66XnJ+7iZGSCh/3cG49JjVIUYB
	DkYlHt4LXHfDhFgTy4orcw8xSnAwK4nwCkUBhXhTEiurUovy44tKc1KLDzFKc7AoifPO3PU+
	REggPbEkNTs1tSC1CCbLxMEp1cB4U0CHb7lp5roO4f+8W8OS4/+3yJ/4kSD78d83dfcNkc5L
	45Tn3eDPF5wa9TB3mvjxCm07+y91ZY2zaq7f+DWhWn9ZOV9LYPqzhdaf/ul8MFN6/PntPavQ
	feufTZswjbfj6pvFd7ov8LzWq0vyl11QKXeELfCO36s3Twq5DpU23vkwrWnXi12uSizFGYmG
	WsxFxYkAoSMRB2ECAAA=

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