🚀 go-pugleaf

In article <9508211033.aa04653@kewszeg.UUCP>,
 <halasz@kewszeg.norden1.com> wrote:
>halasz@caip.rutgers.edu writes:
>In article <411j5n$3va@goanna.cs.rmit.edu.au>, ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
>:  ....
>Yes, and the declaration of "exit", "main", and "exit(0)" require that this
>be hidden from the C-programmer, and that is a mistake.
>:  -- if you want to use the "native" status codes in some operating system,
>:     you will have to use a "native" function to do that, and it isn't the
>Bad dezign in the standard.

I see, so if 10 OS's all have completely different ways of signifying
success and failure (ints vs. strings, etc), then the C standard should
have some way of addressing all of those possibilities?  What nonsense.

There is no way that the standard for the C language can predict all
the ways in which an OS expects to be notified of status.  All it
can do is come up with some uniform way of indicating status, and
then let the OS/startup code intrpret that uniformly specified value,
translating it into the OS's "native" status format if necessary.


>:     _C_ standard's business to dictate what _that_ function looks like.
>No, it is the standard s bizness to take it from the OS.
>:  -- if you want a PORTABLE way to terminate with success/failure, use
>:     exit(0) or exit(EXIT_SUCCESS)/exit(EXIT_FAILURE)
>No, "exit(0)" is not portable, even if the standard decrees it.  The _one_
>portable means of handling this is to hide the valus under macro, and their
>types under a macro or defind type.

Why do you keep insisting that this is the case, when it so clearly is
not?  If exit(0) is defined to have the exact same effect as
exit(EXIT_SUCCESS), then how can one be portable and not the other?
exit(0) does NOT mean that a 0 is specified to the OS as the status;
it means that success is specified to the OS, in whatever form that
may take (with some form of translation taking place, if necessary).

>
>:  -- if exit(N) for some other value of N happens to be useful in your
>:     operating system, that's nice, but "You didn't read it here".
>No, the standard in effect prohibits all other valus than the required, by
>requiring "exit(0)" to be effectivlie the same as "exit(EXIT_SUCCESS)".

Yes, the standard does require this.  How does that prohibit all other
values?  All it does is say that other values have effects which
must be defined by the implementation.

>
>: It has been a long time since I used VMS or VAX-11 C, but I thought there
>: was a SYS$EXIT(longword) function you could use to terminate "natively".
>Look, are we interested in C, or not?  If we are, then we want the C-function
>to be permitted all of the OS s program-exits.

Sure, that would be nice.  But since OS's can have many different ways of
specifying program-exits, there's no way the C language standard can
cover them all.  This does NOT mean that we just can't do it.  It only
means that we can't do it in a way which has the same meaning on ALL
OS's.  In other words, we must take advantage of implementation-defined
behavior.

[snip]

>The restriction on "exit" means that for all programmers the arguments
>are restricted to 0, "EXIT_SUCCESS", and "EXIT_FAILURE", even when the
>programmer knows that other status would in his case make more sens
>(not intendind to uze the code on other-like computers).  Even the Unix-
>programmer is required to uze another function than exit, if he wants to
>exit with 2 or 3 or ..., much less the poor VMS-programmer, who would
>want to exit with 0 for to mark a general warning with no special content.

To what restriction on exit are you referring?  I know of no
restriction which prevents the programmer from putting exit(2) in her
program if she so desires.  And in UNIX it is very well defined what
happens in this case: the parent process will receive the value 2 as
the exit status of the child process in which this program was running
when the child process is reaped (sorry for the implementation-specific
discussion).  Saying that "the Unix-programmer is required to use
another function than exit" is simply false.

The only caveat is that exit(2) will have different meaning for a
different OS.

-Jon