home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ogicse!das-news.harvard.edu!spdcc!dirtydog.ima.isc.com!karl
- From: karl@ima.isc.com (Karl Heuer)
- Newsgroups: comp.lang.c
- Subject: Re: main()
- Message-ID: <1992Sep11.223347.5184@ima.isc.com>
- Date: 11 Sep 92 22:33:47 GMT
- Article-I.D.: ima.1992Sep11.223347.5184
- References: <1992Sep4.191347.27577@klaava.Helsinki.FI> <1992Sep10.003907.15391@sq.sq.com> <MJN.92Sep10232853@pseudo.uucp>
- Sender: usenet@ima.isc.com (news)
- Organization: Interactive Systems, Cambridge, MA 02138-5302
- Lines: 21
-
- In article <MJN.92Sep10232853@pseudo.uucp> mjn@pseudo.uucp (Murray Nesbitt) writes:
- >In my opinion, the Standards committee broke exit(). Suppose I am [using
- >VMS]. How do I explicitly return the value 0 to VMS from my program?
-
- You call sys$exit(0).
-
- Suppose I'm using a system on which the native system call takes a string
- argument instead of a number. (A much better model, I think.) Should I blame
- X3J11 for insisting that exit() doesn't accomodate me?
-
- >Why is there a reluctance to use [EXIT_SUCCESS and EXIT_FAILURE]?
-
- From my own perspective, it's because they aren't expressive enough -- I
- like to have Unix programs return 0 for "Yes", 1 for "No", 2 for "Bad args"
- (e.g. can't open the file whose name was specified as an argument), 3 for
- "Internal error" (including insufficient memory). For true portability,
- I should use different symbolic names for these (and have the non-zero values
- all expand to the value of EXIT_FAILURE on sufficiently impoverished systems),
- but I haven't gotten around to reorganizing my existing code that way, yet.
-
- Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
-