Odd trap return status

Odd trap return status

[Peter Stephenson]

% inner() { trap 'return 1' EXIT; return 2; } 
% outer() { inner; print Not executed; return 3; }
% outer; print $?
2

I think that ought to be 1.  Somehow the return value of inner is being
preserved instead of the value specified.  (Remember the EXIT trap runs
in the scope of `outer'; this seems to be working OK.)

Unfortunately there's no other shell with which to compare since they
don't apply EXIT traps to functions.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

PATCH: Re: Odd trap return status

[Peter Stephenson]

Peter Stephenson wrote:
> % inner() { trap 'return 1' EXIT; return 2; } 
> % outer() { inner; print Not executed; return 3; }
> % outer; print $?
> 2
> 
> I think that ought to be 1.

We save and restore a whole load of status for all traps, which isn't
necessary if they are fake traps which are never caused by signals.
This is a minimal patch for that.

However, are execsave() and execrestore() necessary now we queue signals
until some suitable point?  There's a message from Zoltan (2751) some
time ago suggesting they shouldn't be any more (that was way before we'd
actually done anything about the problem).  I'm too cowardly to remove
them for traps triggered by real signals without more thought.

Index: Src/signals.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/signals.c,v
retrieving revision 1.20
diff -u -r1.20 signals.c
--- Src/signals.c	18 Jun 2001 09:29:48 -0000	1.20
+++ Src/signals.c	29 May 2002 14:10:58 -0000
@@ -945,7 +945,16 @@
     *sigtr |= ZSIG_IGNORED;
 
     lexsave();
-    execsave();
+    if (sig != SIGEXIT && sig != SIGDEBUG) {
+	/*
+	 * SIGEXIT and SIGDEBUG are always run synchronously, so we don't
+	 * need to save and restore the state.
+	 *
+	 * Do we actually need this at all now we queue signals
+	 * for handling in places where they won't cause trouble?
+	 */
+	execsave();
+    }
     breaks = 0;
     runhookdef(BEFORETRAPHOOK, NULL);
     if (*sigtr & ZSIG_FUNC) {
@@ -972,7 +981,8 @@
 	trapret = trapreturn;
     else if (errflag)
 	trapret = 1;
-    execrestore();
+    if (sig != SIGEXIT && sig != SIGDEBUG)
+	execrestore();
     lexrestore();
 
     if (trapret > 0) {

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: PATCH: Re: Odd trap return status

[Bart Schaefer]

On Wed, 29 May 2002, Peter Stephenson wrote:

> We save and restore a whole load of status for all traps, which isn't
> necessary if they are fake traps which are never caused by signals.
> This is a minimal patch for that.

Hrm.  This seems wrong to me.  TRAPDEBUG definitely MUST NOT affect the
return code, etc., of the surrounding function.

It would seem to me that even TRAPEXIT should not change values such as
list_pipe_job and badcshglob.

> However, are execsave() and execrestore() necessary now we queue signals
> until some suitable point?

I think they still are needed, though maybe not in as many cases and
perhaps not for all the globals that currently are saved.

Re: PATCH: Re: Odd trap return status

[Peter Stephenson]

Bart Schaefer wrote:
> On Wed, 29 May 2002, Peter Stephenson wrote:
> 
> > We save and restore a whole load of status for all traps, which isn't
> > necessary if they are fake traps which are never caused by signals.
> > This is a minimal patch for that.
> 
> Hrm.  This seems wrong to me.  TRAPDEBUG definitely MUST NOT affect the
> return code, etc., of the surrounding function.
> 
> It would seem to me that even TRAPEXIT should not change values such as
> list_pipe_job and badcshglob.

I think you may be missing the point a bit, unless I am...

  trap 'return 1' DEBUG

would already cause a return from the enclosing function, only the
return status would get lost.  I haven't changed the command flow at
all, only the effect on status variables.  So it seems to me illogical
to insist that the return value be lost.  (However, you can argue that
applies to traps from real signals, too.)

The other stuff --- list_pipe_job, etc. --- should be maintained
consistently anyway.  The point about saving it was not because the
function shouldn't affect the surroundings --- if it was, we would need
to do it in a whole load of other cases such as precmd --- but because
the signal could happen at a point where the shell was already in the
middle of executing something else, and this could cause an inconsistent
state which we needed to recover from.

I think.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: PATCH: Re: Odd trap return status

[Bart Schaefer]

On Wed, 29 May 2002, Peter Stephenson wrote:

> I think you may be missing the point a bit, unless I am...
>
>   trap 'return 1' DEBUG
>
> would already cause a return from the enclosing function, only the
> return status would get lost.  I haven't changed the command flow

Right, but

	foo () {
	 trap 'false' DEBUG
	 true
	}

should not cause the exit status of foo to be nonzero.  Really the worse
case is

	foo() {
	 trap 'echo This command succeeds' DEBUG
	 false
	}

which should not cause foo() to return a zero status.  Installing a debug
trap shouldn't change the behavior of the debugged code unless it *also*
(intentionally) changes the command flow.

Re: PATCH: Re: Odd trap return status

[Peter Stephenson]

Bart Schaefer wrote:
> Right, but
> 
> 	foo () {
> 	 trap 'false' DEBUG
> 	 true
> 	}
> 
> should not cause the exit status of foo to be nonzero.

This is already handled specially.  I think the code was sort of working
before execsave()/execrestore() got introduced for safety rather than
for logic.

	if (sigtrapped[SIGDEBUG]) {
	    exiting = donetrap;
	    ret = lastval;
	    dotrap(SIGDEBUG);
	    lastval = ret;
	    donetrap = exiting;
	    noerrexit = oldnoerrexit;
	}

> Installing a debug
> trap shouldn't change the behavior of the debugged code unless it *also*
> (intentionally) changes the command flow.

That's going to be kind of tricky with the code quoted above, which I
missed before.  But I don't feel like digging an even deeper hole.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************