Re: bug: return doesn't accept negative numbers
2011-08-08, 13:55(-07), Linda Walsh: [...] and both 'exit' and 'return' should return error ERANGE if --posix is set, and -1 is given. Iinvalid option doesn't make as much sense, in this situtation, if it was -k or -m, sure...but in this case, it's a fact that --posix artificially limits exit values apart from what is allowed in most prog langs (which accept negative, but still return results 0xff), so for Posix, it's a matter of disallowing a 'normal range', vs. it being an invalid option [...] POSIX doesn't prevent a shell from accepting -1 (or for doing anything like eject a cd or output an error or turn red upon return -1). It just says an *application* should not use return -1, that is that if one wants to write a portable script, she shouldn't use return -1. Many POSIX shells accept return -1 $ ksh93 -c 'f() return -1; f; echo $?' 255 $ pdksh -c 'f() return -1; f; echo $?' -1 $ zsh -c 'f() return -1; f; echo $?' -1 $ posh -c 'f() return -1; f; echo $?' return: invalid option -- '1' 1 $ posh -c 'f() return -- -1; f; echo $?' -1 $ mksh -c 'f() return -1; f; echo $?' mksh: return: -1: unknown option 1 $ mksh -c 'f() return -- -1; f; echo $?' -1 But as you can see the result varies, so one shouldn't use return -1 if one wants to be portable accross POSIX shells. Also note: $ zsh -c 'f() return -1; f; echo $?' -1 $ zsh -c 'f() return -1; (f); echo $?' 255 That is even in shells that support arbitrary numbers for return, as soon as they are cast to exit status, they are 255ed. -- Stephane
Re: bug: return doesn't accept negative numbers
On Mon, Aug 8, 2011 at 8:42 AM, Bob Proulx b...@proulx.com wrote: People sometimes read the POSIX standard today and think it is a design document. Let me correct that misunderstanding. It is not. POSIX is an operating system non-proliferation treaty. Love it! jon.
Re: bug: return doesn't accept negative numbers
` Stephane CHAZELAS wrote: 2011-08-08, 13:55(-07), Linda Walsh: [...] and both 'exit' and 'return' should return error ERANGE if --posix is set, and -1 is given. Iinvalid option doesn't make as much sense, in this situtation, if it was -k or -m, sure...but in this case, it's a fact that --posix artificially limits exit values apart from what is allowed in most prog langs (which accept negative, but still return results 0xff), so for Posix, it's a matter of disallowing a 'normal range', vs. it being an invalid option [...] POSIX doesn't prevent a shell from accepting -1 (or for doing anything like eject a cd or output an error or turn red upon return -1). It just says an *application* should not use return -1, that is that if one wants to write a portable script, she shouldn't use return -1. Many POSIX shells accept return -1 $ ksh93 -c 'f() return -1; f; echo $?' 255 $ pdksh -c 'f() return -1; f; echo $?' -1 $ zsh -c 'f() return -1; f; echo $?' -1 $ posh -c 'f() return -1; f; echo $?' return: invalid option -- '1' 1 $ posh -c 'f() return -- -1; f; echo $?' -1 $ mksh -c 'f() return -1; f; echo $?' mksh: return: -1: unknown option 1 $ mksh -c 'f() return -- -1; f; echo $?' -1 But as you can see the result varies, so one shouldn't use return -1 if one wants to be portable accross POSIX shells. Also note: $ zsh -c 'f() return -1; f; echo $?' -1 $ zsh -c 'f() return -1; (f); echo $?' 255 That is even in shells that support arbitrary numbers for return, as soon as they are cast to exit status, they are 255ed. Displaying -1 or 255 is fine. -1 would be an enhancement, but certainly not expected as it isn't clearly that the real value is an 8-bit integer... Only the broken shells that attempt to validate options for return (despite, it being documented to have none), return invalid values. I would deduce that it is only non-posix compliant shells that return '1', ... as they are trying to validate return's options (which doesn't take any)...
Re: bug: return doesn't accept negative numbers
On 08/08/2011 08:14 PM, Chet Ramey wrote: On 8/8/11 9:42 PM, Mike Frysinger wrote: On Monday, August 08, 2011 21:20:29 Chet Ramey wrote: On 8/8/11 8:53 AM, Eric Blake wrote: However, you are on to something - since bash allows 'exit -1' as an extension, it should similarly allow 'return -1' as the same sort of extension. The fact that bash accepts 'exit -1' and 'exit -- -1', but only 'return -- -1', is the real point that you are complaining about. That's a reasonable extension to consider for the next release of bash. i posted a patch for this quite a while ago. not that it's hard to code. Sure. It's just removing the three lines of code that were added between bash-3.2 and bash-4.0. The question was always whether that's the right thing to do, and whether the result will behave as Posix requires. Yes, the result will behave as POSIX requires. POSIX requires that 'return' and 'exit' need not support '--' (since they are special builtins that do not specifically require compliance with the generic rules on option parsing), that they need not support options, and that if their optional argument is present, it need not be supported if it is not a non-negative integer no greater than 255. But they are _not_ required to reject any input outside the above constraints - therefore, an extension that supports '--', an extension that parses '-- -1' as 255, and an extension that parses any option that looks like a negative number such as 'exit -1', are ALL valid extensions permitted by POSIX, and need not be disabled by --posix, but can be available always. ksh does just that: 'return -1' and 'return -- -1' are always accepted and both result in the same behavior as the POSIX-mandated 'return 255'; ksh also has an extension where 'return --help' prints help, although bash uses 'help return' for this purpose. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: bug: return doesn't accept negative numbers
On 8/9/11 8:53 AM, Eric Blake wrote: On 08/08/2011 08:14 PM, Chet Ramey wrote: On 8/8/11 9:42 PM, Mike Frysinger wrote: On Monday, August 08, 2011 21:20:29 Chet Ramey wrote: On 8/8/11 8:53 AM, Eric Blake wrote: However, you are on to something - since bash allows 'exit -1' as an extension, it should similarly allow 'return -1' as the same sort of extension. The fact that bash accepts 'exit -1' and 'exit -- -1', but only 'return -- -1', is the real point that you are complaining about. That's a reasonable extension to consider for the next release of bash. i posted a patch for this quite a while ago. not that it's hard to code. Sure. It's just removing the three lines of code that were added between bash-3.2 and bash-4.0. The question was always whether that's the right thing to do, and whether the result will behave as Posix requires. Yes, the result will behave as POSIX requires. That's not exactly what I meant. I know what Posix says. The question is whether or not the code does that, and that's what I have to verify. The change went in (three years ago) to solve a specific issue, so I have to make sure we're not going backwards here. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bug: return doesn't accept negative numbers
On 08/07/2011 02:35 PM, Linda Walsh wrote: Eric Blake wrote: On 08/05/2011 05:41 PM, Linda Walsh wrote: Seem to fail on any negative number, but 'exit status' is defined as a short int -- not an unsigned value (i.e. -1 would return 255). In bash, 'return -- -1' sets $? to 255 (note the --). But since that is already an extension (POSIX does not require 'return' to support -- any more than it is required to support an argument of -1), I agree with your argument that bash would be more useful if, as an extension to POSIX, it would handle 'return -1' - in fact, that would match ksh behavior. Conversely, since portable code already can't use it, it's no skin off my back if nothing changes here. --- How about portable code using: (exit -1); return That's not portable, either. exit is allowed to reject -1 as invalid. POSIX is clear that exit and return have the same constraints - if an argument is provided, it must be 0-255 to be portable. However, you are on to something - since bash allows 'exit -1' as an extension, it should similarly allow 'return -1' as the same sort of extension. The fact that bash accepts 'exit -1' and 'exit -- -1', but only 'return -- -1', is the real point that you are complaining about. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: bug: return doesn't accept negative numbers
Eric Blake wrote: (exit -1); return That's not portable, either. exit is allowed to reject -1 as invalid. POSIX is clear that exit and return have the same constraints - if an argument is provided, it must be 0-255 to be portable. However, you are on to something - since bash allows 'exit -1' as an extension, it should similarly allow 'return -1' as the same sort of extension. The fact that bash accepts 'exit -1' and 'exit -- -1', but only 'return -- -1', is the real point that you are complaining about. Clearly(? :-)), 'return' should accept -1, in 'normal mode', and both 'exit' and 'return' should return error ERANGE if --posix is set, and -1 is given. Iinvalid option doesn't make as much sense, in this situtation, if it was -k or -m, sure...but in this case, it's a fact that --posix artificially limits exit values apart from what is allowed in most prog langs (which accept negative, but still return results 0xff), so for Posix, it's a matter of disallowing a 'normal range', vs. it being an invalid option Would that be sound reasoning?
Re: bug: return doesn't accept negative numbers
Bob Proulx wrote: Linda Walsh wrote: Bob Proulx wrote: Exit codes should be in the range 0-255. --- I suppose you don't realize that 'should' is a subjective opinion that sometimes has little to do with objective reality. Sigh. Okay. Keep in mind that turn about is fair play. You are giving it to me. Please be gracious on the receiving end of it. --- I *do* love it! I strive vociferously, to not be hypocritical, so what I put out, feel free to give back -- where I get in trouble, is that is how I operate with other people (not from the start, but given time, I start reciprocating their behavior and language toward me...) Mirroring, or adopting another's form of address/speech, etc, is usually considered a good thing to develop rapport, (Ha!)... -- expcept when the other person is being a jerk!...then it causes problems... Unfortunately unless I catch myself, 'mirroring' is almost unconscious for me. But it works to my disadvantage as often or more so in society these days (with everyone being so 'friendly' by default [not!]). So try to buffer and average input and start from a 'positive' friendly point -- things go up or down from there. You do realize that you should comply with documented interfaces. Why? Because that is the way the interface specification is documented. If you want things to work easily then most generally the easiest way is to follow the documented practice. Unless you have an exceptional reason for doing something different from the documented interface then actively doing anything else is actively trying to be broken. Ok, lets look at what you say below... POSIX was intended to document the existing behavior so that if you followed the specification then you would have some hope of being able to run successfully on multiple systems. And it was intended to curb the differences from becoming greater than they were already. It tries to reign in the divergent behaviors so that there won't be more differences than already exist. This is what POSIX says about it: void exit(int status); The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE, or any other value, though only the least significant 8 bits (that is, status 0377) shall be available to a waiting parent process. Exactly!. 'int status' means it takes a 'signed' value. It will and it with 0377, given, but the *input* allows positive and negative numbers. Then they will be masked to 8 bits. That's all I'm asking for.
Re: bug: return doesn't accept negative numbers
On 8/8/11 8:53 AM, Eric Blake wrote: However, you are on to something - since bash allows 'exit -1' as an extension, it should similarly allow 'return -1' as the same sort of extension. The fact that bash accepts 'exit -1' and 'exit -- -1', but only 'return -- -1', is the real point that you are complaining about. That's a reasonable extension to consider for the next release of bash. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bug: return doesn't accept negative numbers
On Monday, August 08, 2011 21:20:29 Chet Ramey wrote: On 8/8/11 8:53 AM, Eric Blake wrote: However, you are on to something - since bash allows 'exit -1' as an extension, it should similarly allow 'return -1' as the same sort of extension. The fact that bash accepts 'exit -1' and 'exit -- -1', but only 'return -- -1', is the real point that you are complaining about. That's a reasonable extension to consider for the next release of bash. i posted a patch for this quite a while ago. not that it's hard to code. -mike signature.asc Description: This is a digitally signed message part.
Re: bug: return doesn't accept negative numbers
On 8/8/11 9:42 PM, Mike Frysinger wrote: On Monday, August 08, 2011 21:20:29 Chet Ramey wrote: On 8/8/11 8:53 AM, Eric Blake wrote: However, you are on to something - since bash allows 'exit -1' as an extension, it should similarly allow 'return -1' as the same sort of extension. The fact that bash accepts 'exit -1' and 'exit -- -1', but only 'return -- -1', is the real point that you are complaining about. That's a reasonable extension to consider for the next release of bash. i posted a patch for this quite a while ago. not that it's hard to code. Sure. It's just removing the three lines of code that were added between bash-3.2 and bash-4.0. The question was always whether that's the right thing to do, and whether the result will behave as Posix requires. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bug: return doesn't accept negative numbers
Chet Ramey wrote: Sure. It's just removing the three lines of code that were added between bash-3.2 and bash-4.0. The question was always whether that's the right thing to do, and whether the result will behave as Posix requires. That explains why I never ran into this before! You broke previous compat! Was there a note to this effect? I don't remember it, but could have easily missed it... So why not limit that behavior to when --posix is in effect?
Re: bug: return doesn't accept negative numbers
Bob Proulx wrote: Linda Walsh wrote: How about portable code using: (exit -1); return It's ugly, but would seem to be the portable/official way to do this. Exit codes should be in the range 0-255. --- I suppose you don't realize that 'should' is a subjective opinion that sometimes has little to do with objective reality. It is true, that when you display a signed char, non-signed- -extended, in a 16, 32 or 64 bit format, you see 255, and certainly, no one (including myself) would suggest 'sign extending' an error code, as that would make it other than what it was. But just because it displays only as 0-255 under most circumstances is no reason for ignoring the implementation in all the main languages when the standard was written as accepting signed short integers. The same 'open group' that wrote posix wrote a C standard , and they defined it's exit val as taking a short int as well So they were inconsistent. Bash itself is inconsistent in that it accepts exit values the same as every other program, but limits return values to a particular subset.
Re: bug: return doesn't accept negative numbers
On 8/7/11 4:35 PM, Linda Walsh wrote: --- How about portable code using: (exit -1); return return $(( -1 255 )) -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bug: return doesn't accept negative numbers
On 8/7/11 6:03 PM, Linda Walsh wrote: Bash itself is inconsistent in that it accepts exit values the same as every other program, but limits return values to a particular subset. Bash accepts any value you want to give to `return' and strips it to 8 bits, as the standard allows. Read the error message closely: it says `invalid option'. return doesn't accept any options, even ones that might possibly be interpreted as negative status values -- which the standard doesn't allow anyway. As Eric Blake showed, `return -- -1' works just fine, and sets $? to 255. If you don't want to type the three extra characters, use the $(( ... )) idiom I posted earlier. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bug: return doesn't accept negative numbers
Linda Walsh wrote: Bob Proulx wrote: Exit codes should be in the range 0-255. --- I suppose you don't realize that 'should' is a subjective opinion that sometimes has little to do with objective reality. Sigh. Okay. Keep in mind that turn about is fair play. You are giving it to me. Please be gracious on the receiving end of it. You do realize that you should comply with documented interfaces. Why? Because that is the way the interface specification is documented. If you want things to work easily then most generally the easiest way is to follow the documented practice. Unless you have an exceptional reason for doing something different from the documented interface then actively doing anything else is actively trying to be broken. It is true, that when you display a signed char, non-signed- -extended, in a 16, 32 or 64 bit format, you see 255, and certainly, no one (including myself) would suggest 'sign extending' an error code, as that would make it other than what it was. But just because it displays only as 0-255 under most circumstances is no reason for ignoring the implementation in all the main languages when the standard was written as accepting signed short integers. You appear to be confusing programming subroutine return values with program exit values. Those are two completely different things. I agree they are related concepts. We often try to force fit one into the other. But just the same they are different things. In the imortal words of Dr. Egon Spengler, Don't cross the streams. On the topic of exit values... Back in the original V7 Unix the exit(2) call was documented simply as: The low-order 8 bits of status are available to the parent process. And that is all that it said. And the code was written in assembly without reference to whether it should be signed or not. The oldest BSD version of the sources I have access to was a little more helpful and said: The low-order 8 bits of status are available to the parent process. (Therefore status should be in the range 0 - 255) Since V7 dates to 1979 and the BSD version I looked at dates at least to from that same era it has been this way for a very long time. I grep'd through the V7 sources and found not one instance where a negative value was returned. (However there are some instances where no value was specified and the accumulator value was returned.) The same 'open group' that wrote posix wrote a C standard , and they defined it's exit val as taking a short int as well So they were inconsistent. People sometimes read the POSIX standard today and think it is a design document. Let me correct that misunderstanding. It is not. POSIX is an operating system non-proliferation treaty. At the time it was created there were different and divergent systems that was making it impossible to write code for one system that would work on another system. They were all Unix systems. But they weren't the same Unix system. Code from one system would break on another system. What started out as small variances created very large problems. People found it very difficult to write portable code because these differences were getting out of hand. POSIX was intended to document the existing behavior so that if you followed the specification then you would have some hope of being able to run successfully on multiple systems. And it was intended to curb the differences from becoming greater than they were already. It tries to reign in the divergent behaviors so that there won't be more differences than already exist. This is what POSIX says about it: void exit(int status); The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE, or any other value, though only the least significant 8 bits (that is, status 0377) shall be available to a waiting parent process. It says that because that was the existing practice common to all Unix systems at the time. (My understanding is that VMS uses a different exit status convention. And so that is the reason for using the EXIT_SUCCESS and EXIT_FAILURE macros so that the same source could compile on VMS and still function correctly there.) My finishing gratuitous comment is that unfortunately people are now in the present day using POSIX as a design document. And design by committee never produces great results. But it is what we have to work with today because there isn't any better alternative. Bob
Re: bug: return doesn't accept negative numbers
Chet Ramey wrote: On 8/7/11 6:03 PM, Linda Walsh wrote: Bash itself is inconsistent in that it accepts exit values the same as every other program, but limits return values to a particular subset. Bash accepts any value you want to give to `return' and strips it to 8 bits, as the standard allows. Read the error message closely: it says `invalid option'. return doesn't accept any options Does 'exit' accept any options? No. It doesn't complain. I would assert, that 'return', since it accepts no options, cannot have an 'invalid option', (there are no valid options), therefore, any argument to should attempt to be parsed as a number. Else, I would ask: If -1 is an invalid option, what are valid options...well, as you said, it accepts no options, so it shouldn't be possible for it to return a validation on the acceptability of something as an argument -- as the option parser should never be called on it any more than it is called on exit. As a nice enhancement, you could just default to accepting any expression that returned a number (i.e. treat it as the interior of a (()), vs. requiring that one use $(((expr))) as is now acceptable, and explicitly mention that return $status+0x80 is a bash enhancement... Of course to return -1, apparently one can also use return $(-1)...there are plenty of ways to get around it... that wasn't the point. if shouldn't be trying to parse options any more than 'exit' does. example of a valid option It's not about getting around the bug -- it's that it shouldn't be checking for options in the first place!
bug: return doesn't accept negative numbers
I guess I don't use negative return codes that often in shell, but I use them as exit codes reasonably often. 'return' barfs on return -1... Since return is defined to take no options, and ONLY an integer, as the return code, it shouldn't be hard to fix. Seem to fail on any negative number, but 'exit status' is defined as a short int -- not an unsigned value (i.e. -1 would return 255).
Re: bug: return doesn't accept negative numbers
On 08/05/2011 05:41 PM, Linda Walsh wrote:
I guess I don't use negative return codes that often in shell, but
I use them as exit codes reasonably often.
'return' barfs on return -1...
Since return is defined to take no options, and ONLY an integer,
as the return code, it shouldn't be hard to fix.
According to POSIX, it's not broken in the first place. Portable shell
is requires to pass an unsigned decimal integer, no greater than 255,
for defined behavior.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#return
Seem to fail on any negative number, but 'exit status' is defined
as a short int -- not an unsigned value (i.e. -1 would return 255).
In bash, 'return -- -1' sets $? to 255 (note the --). But since that is
already an extension (POSIX does not require 'return' to support -- any
more than it is required to support an argument of -1), I agree with
your argument that bash would be more useful if, as an extension to
POSIX, it would handle 'return -1' - in fact, that would match ksh
behavior. Conversely, since portable code already can't use it, it's no
skin off my back if nothing changes here.
$ bash -c 'f() { return -- -1; }; f; echo $?'
255
$ bash -c 'f() { return -1; }; f; echo $?'
bash: line 0: return: -1: invalid option
return: usage: return [n]
2
$ dash -c 'f() { return -- -1; }; f; echo $?'
return: 1: Illegal number: --
$ dash -c 'f() { return -1; }; f; echo $?'
return: 1: Illegal number: -1
$ ksh -c 'f() { return -- -1; }; f; echo $?'
255
$ ksh -c 'f() { return -1; }; f; echo $?'
255
$
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
Re: bug: return doesn't accept negative numbers
Eric Blake wrote: Linda Walsh wrote: I guess I don't use negative return codes that often in shell, but I use them as exit codes reasonably often. For all of the reasons Eric mentioned you won't ever actually be able to see a negative result of an exit code however. 'return' barfs on return -1... Since return is defined to take no options, and ONLY an integer, as the return code, it shouldn't be hard to fix. According to POSIX, it's not broken in the first place. Portable shell is requires to pass an unsigned decimal integer, no greater than 255, for defined behavior. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#return The reason for that is for compatibility. Originally the exit status was returned in a 16 bit integer with the lower 8 bit byte holding the exit code and the upper 8 bit byte holding the status. The wait.h macros WTERMSIG et al were used to extract that information. (I don't know if all of that is still true but that is the way it used to be.) And so in the C programming man page for exit(3) it says: man 3 exit The exit() function causes normal process termination and the value of status 0377 is returned to the parent (see wait(2)). Note the status 0377 part. That is an octal 0377 or 255 decimal or 0xFF hexadecimal or just the lower 8 bits. Trying to return a value that won't fit into 8 bits just isn't possible. The traditional man pages always described the size as an 8 bit value and specified the range as 0 through 255 implying that it was an unsigned value. Historical documentation for exit(3) http://www.freebsd.org/cgi/man.cgi?query=exitapropos=0sektion=3manpath=2.9.1+BSDformat=html Now you might argue that -1 is always going to be all ones in two's complement. Sure. But traditionally it has always been unsigned. Bob
Re: bug: return doesn't accept negative numbers
return (and exit) returns an exit code between 0 and 255. Zero means true and anything else means false If you want a function to return a value, use printf or echo. On Fri, Aug 5, 2011 at 6:41 PM, Linda Walsh b...@tlinx.org wrote: I guess I don't use negative return codes that often in shell, but I use them as exit codes reasonably often. 'return' barfs on return -1... Since return is defined to take no options, and ONLY an integer, as the return code, it shouldn't be hard to fix. Seem to fail on any negative number, but 'exit status' is defined as a short int -- not an unsigned value (i.e. -1 would return 255). -- Visit serverfault.com to get your system administration questions answered.
Re: bug: return doesn't accept negative numbers
Linda Walsh wrote: Seem to fail on any negative number, but 'exit status' is defined as a short int -- not an unsigned value (i.e. -1 would return 255). Bob Proulx wrote: Eric Blake wrote: Linda Walsh wrote: I guess I don't use negative return codes that often in shell, but I use them as exit codes reasonably often. For all of the reasons Eric mentioned you won't ever actually be able to see a negative result of an exit code however. I never said anything about 'seeing' -1, in fact, I stated just that -1 would return 255. return says 'if no args are given' will return exit status of the last command executed', so (exit -1);echo $? = 255 (exit -2);echo $? = 254 ... Which is also the way it works in 'C', and perl. AFAIK, from a compiler perspective, if the value is able to be represented as a signed-8-bit quantity, conversion is done (i.e. short int becomes signed char). Seems that return should handle the same exit values as 'exit'. Isn't return supposed to be the 'exit value' of a function?
