Re: bug: return doesn't accept negative numbers

[Bob Proulx]

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