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
