From: Bart Schaefer <email@example.com>
To: Zsh hackers list <firstname.lastname@example.org>
Subject: Re: using trap function to cleanup and exit?
Date: Fri, 15 Apr 2022 15:27:05 -0700 [thread overview]
Message-ID: <CAH+w=7YAdFP1AT6LuNJ3fvqkLRW5O+Pb6pzp+4zMGWJxwZSA2g@mail.gmail.com> (raw)
On Thu, Apr 14, 2022 at 2:29 PM Bart Schaefer <email@example.com> 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.
However, the test for whether to increment trap_return again on the
way out is dependent on trap_state == TRAP_STATE_PRIMED, so if we
change trap_state we're never going to increment (or decrement,
actually) trap_return again. (It may, however, get restored from a
stacked value.) I can imagine there being some side-effect of this
from using a mix of "return" and "exit" from traps or from functions
that might be called by traps, but have no good idea how to exercise
such a code path.
I guess I'll go ahead and push this and if someone spots a problem we
can do a revision.
next prev parent reply other threads:[~2022-04-15 22:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-10 15:46 Greg Klanderman
2022-04-10 15:57 ` Peter Stephenson
2022-04-10 16:12 ` Greg Klanderman
2022-04-10 16:30 ` Greg Klanderman
2022-04-10 18:15 ` Lawrence Velázquez
2022-04-14 5:13 ` Greg Klanderman
2022-04-10 20:49 ` Bart Schaefer
2022-04-10 20:55 ` Bart Schaefer
2022-04-14 5:57 ` Greg Klanderman
2022-04-14 21:29 ` Bart Schaefer
2022-04-14 23:35 ` Bart Schaefer
2022-04-17 17:08 ` Daniel Shahaf
2022-04-15 22:27 ` Bart Schaefer [this message]
2022-04-19 18:42 ` Peter Stephenson
2022-04-19 18:55 ` Peter Stephenson
2022-04-19 21:22 ` Bart Schaefer
2022-04-20 8:16 ` Peter Stephenson
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
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).