Re: using trap function to cleanup and exit?

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Tue, 2022-04-19 at 19:42 +0100, Peter Stephenson wrote:
> On Fri, 2022-04-15 at 15:27 -0700, Bart Schaefer wrote:
> > On Thu, Apr 14, 2022 at 2:29 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > > 
> > > [I] would prefer that another set of eyes review
> > > the code change.
> > 
> > To expand on that a bit ...
> > 
> > The BIN_RETURN branch checks that (trap_return == -2) which is a
> > pretty specific number.  exec.c says:
> >  * This is only active if we are inside a trap, else its value
> >  * is irrelevant.  It is initialised to -1 for a function trap and
> >  * -2 for a non-function trap and if negative is decremented as
> >  * we go deeper into functions and incremented as we come back up.
> >  * The value is used to decide if an explicit "return" should cause
> >  * a return from the caller of the trap; it does this by setting
> >  * trap_return to a status (i.e. a non-negative value).
> > 
> > My interpretation is that, since we are in an explicit "exit" rather
> > than an explicit "return", we don't really care how trap_return is
> > set; we're going to force the caller to return, period.
> 
> I just got back and looked, and it's hard to see how this could make
> anything worse.

Very minor comment (entirely cosmetic): it would probably be good
practice to check trap_state != TRAP_STATE_INACTIVE rather than just
trap_state.  Does the following look reasonable?  In fact, it might
be even more logical just to check for PRIMED.

With hindsight, "primed" isn't a great choice of word, it doesn't
indicate what state we are actually at in trap processing, but without
following this all through in more detail I wouldn't like to suggest
another.  (And the resulting
TRAP_STATE_WE_DID_THIS_BUT_WE_HAVENT_YET_DONE_THIS_BECAUSE_WERE_WAITING_FOR_THIS
might not be any better...)

pws

diff --git a/Src/builtin.c b/Src/builtin.c
index b93466ba5..88d69e070 100644
--- a/Src/builtin.c
+++ b/Src/builtin.c
@@ -5720,7 +5720,11 @@ bin_break(char *name, char **argv, UNUSED(Options ops), int func)
 	     * a bad job.
 	     */
 	    if (stopmsg || (zexit(0, ZEXIT_DEFERRED), !stopmsg)) {
-		if (trap_state) 
+		/*
+		 * If the trap is primed but we've hit an explicit exit,
+		 * we should skip any further handling and bail out now.
+		 */
+		if (trap_state != TRAP_STATE_INACTIVE)
 		    trap_state = TRAP_STATE_FORCE_RETURN;
 		retflag = 1;
 		breaks = loops;