Subject: Re: NetBSD master CVS tree commits
To: Bruce Albrecht <Bruce.Albrecht@seag.fingerhut.com>
From: Greg A. Woods <woods@kuma.web.net>
List: current-users
Date: 06/05/1996 16:02:31
[ On Tue, June  4, 1996 at 16:40:36 (-0500), Bruce Albrecht wrote: ]
> Subject: Re: NetBSD master CVS tree commits
>
> Greg A. Woods writes:
>  > > Modified Files:
>  > > 	eval.c 
>  > > Log Message:
>  > > Fix PR/2504: return with no args returns 0 instead of the return value of
>  > > the previous command in functions
>  >  
>  > I think this PR was in error.

I recant.  It seems the Log Message above describes the problem, and not
the fix....

> I wrote this PR, and maybe the fix, I submitted one with my PR.  I was
> seeing an exit value of zero when a function returned with a return
> statement with no parameters, but all of my references (except for the
> O'Reilly ksh book) indicated that this was wrong. I don't have a copy
> of P1003.2, but if you can tell me where it's online, I'll check it
> out.

I don't think the P1003.2 drafts are online anywhere any more.  They've
all been withdrawn pending approval of the final standard, so nobody can
legally give you any possibly archived copy.  ;-)

> Does the following excerpt really talk about the return command, or
> just function exit status?
> 
>  > From P1003.2/D11.2 section 3.9.5, p. 276:
>  > 
>  >  Exit_Status
>  > 
>  >  The exit status of a function definition shall be zero if the function
>  >  was declared successfully; otherwise, it shall be greater than zero.  The
>  >  exit status of a function invocation shall be the exit status of the last
>  >  command executed by the function.

Good question.  No, it doesn't talk about the 'return' command itself.
Return is really a rather trivial little guy though, and he doesn't
really do anything but potentially fiddle with the value of ? (and of
course cause the function to return, be it the last statement or not.

Here's the description from P1003.2/D11.2 p. 305-306:

 3.14.10  return - Return from a function

       return [n]

 The return utility shall cause the shell to stop executing the current
 function or dot script (see 3.14.4).  If the shell is not currently
 executing a function or dot script, the results are unspecified.

 Exit_Status

 The value of the special parameter ? shall be set to n, an unsigned
 decimal integer, or to the exit status of the last command executed if n
 is not specified.  If the value of n is greater than 255, the results are
 undefined.  When return is executed in a trap action (see 3.14.13), the
 ``last command'' is considered to be the command that executed
 immediately preceding the trap action.

 BEGIN_RATIONALE

 3.14.10.1  return Rationale. (This subclause is not a part of P1003.2)

 The behavior of return when not in a function or dot script differs
 between the System V shell and the KornShell.  In the System V shell this
 is an error, whereas in the KornShell, the effect is the same as exit.

 The results of returning a number greater than 255 are undefined because
 of differing practices in the various historical implementations.  Some
 shells AND out all but the low order 8 bits; others allow larger values,
 but not of unlimited size.

 See the discussion of appropriate exit status values in 3.14.7.1.          1

 END_RATIONALE                                                              1

In other words, what a 'return' statement does is set the ? parameter to
'n', and not specifying 'n' is the same as giving "$?".  From there the
clause in 3.9.5 simply can be interpreted to say that the exit status of
the function is the value of the ? parameter at exit.

> Are you saying that without the patched eval.c, /bin/sh on NetBSD is
> returning a non-zero value for the above or for your example below?
> If it is, then I'd like to figure out why my versions of NetBSD
> (Amiga, 1.1 and 1.2_ALPHA) are not functioning as expected.

Nope.  I haven't yet tested any of this with *any* *BSD shell.  ;-)

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>