karl@haddock.ima.isc.com (Karl Heuer) (03/22/89)
In article <6212@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >Another [political issue] was refusal to standardize the common practice of >0=normal, nonzero=error in exit(n), This is not common practice. Even in Unix, the current situation is that (n%256==0) denotes normal exit, (n%256!=0) flags an error. Should Unix change to meet the proposed specification (so that exit(256) will flag an error), or do you want it reworded in such a way that Unix already conforms? Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/22/89)
In article <12111@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes [about my claim that 0=normal nonzero=error in exit(n)]: >This is not common practice. Even in Unix, the current situation is that >(n%256==0) denotes normal exit, (n%256!=0) flags an error. (The reference here is to the fact that only the lowest 8 bits of n are used.) Existing programs almost never use anything other than a return code of 0, 1, or 2. It almost doesn't matter what the standard says about the number of bits used. In fact the standard could simply have said: "...if the value of the exit code is not 0, 1, or 2, it is interpreted in an implementation-dependent manner". That would not affect more than about 0.2% of existing C programs. The current standard affects all of them. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ARPA: dhesi@bsu-cs.bsu.edu
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/22/89)
In article <6268@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >Existing programs almost never use anything other than a return code of >0, 1, or 2. It almost doesn't matter what the standard says about the >number of bits used. In fact the standard could simply have said: >"...if the value of the exit code is not 0, 1, or 2, it is interpreted >in an implementation-dependent manner". That would not affect more >than about 0.2% of existing C programs. The current standard affects >all of them. Not true. Existing UNIX C programs that use exit codes as you describe will continue to work when the UNIX environment is upgraded to ANSI C standard conformance. Existing C programs that rely on UNIX semantics for the exit codes are already nonportable, and the C standard reflects that fact (it doesn't *cause* it). After a long pitched battle, X3J11 at least agreed that 0 could be promised to mean "success" in all conforming implementations. Thus, if you don't want to use the portability macros EXIT_SUCCESS and EXIT_FAILURE, so long as your application is always "successful" even in adverse circumstances you can have it terminate by returning 0 in any conforming hosted environment.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/22/89)
In article <9902@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes (responding to my article in which I say most existing C programs exit with a code of 0, 1, or 2 and that 0=success, nonzero=failure is a common convention): >Not true. Existing UNIX C programs that use exit codes as you describe >will continue to work when the UNIX environment is upgraded to ANSI C >standard conformance. Existing C programs that rely on UNIX semantics >for the exit codes are already nonportable, and the C standard reflects >that fact (it doesn't *cause* it). Scanning through C programming textbooks, which are geared towards a variety of implementations not all under UNIX, we consistently find exit(0) and exit(1) used for success and failure respectively. It doesn't matter that these existing programs are "nonportable", if that means (as it does in this case) "won't work under VAX/VMS". -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ARPA: dhesi@bsu-cs.bsu.edu
scjones@sdrc.UUCP (Larry Jones) (03/23/89)
In article <6268@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > Existing programs almost never use anything other than a return code of > 0, 1, or 2. It almost doesn't matter what the standard says about the > number of bits used. In fact the standard could simply have said: > "...if the value of the exit code is not 0, 1, or 2, it is interpreted > in an implementation-dependent manner". That would not affect more > than about 0.2% of existing C programs. The current standard affects > all of them. No, Rahul, it doesn't affect all of them. Those of us who have been writing REALLY portable code have been using exit(SUCCESS) and exit(FAILURE) all along. ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC scjones@sdrc.UU.NET 2000 Eastman Dr. BIX: ltl Milford, OH 45150 AT&T: (513) 576-2070 "When all else fails, read the directions."
suitti@haddock.ima.isc.com (Stephen Uitti) (03/24/89)
->...most existing C programs exit with a code of 0, 1, or 2 and that ->0=success, nonzero=failure is a common convention): What does "2" commonly mean? "Other kind of error?" I use "0" and "1". I don't use shell scripts much, since C is a much better language (faster, more powerful, easier to support, etc.). Generally, the exit code is irrelevant. I use "0" & "1" mostly to keep "make" happy. ->Scanning through C programming textbooks, which are geared towards a ->variety of implementations not all under UNIX, we consistently find ->exit(0) and exit(1) used for success and failure respectively. ->It doesn't matter that these existing programs are "nonportable", if ->that means (as it does in this case) "won't work under VAX/VMS". What doesn't work? Does the program not compile or die? Does VMS support (or not) exit codes for DCL or something? Will this be fixed if/when DEC provides POSIX support for VMS? Stephen.
henry@utzoo.uucp (Henry Spencer) (03/25/89)
In article <12143@haddock.ima.isc.com> suitti@haddock.ima.isc.com (Stephen Uitti) writes: >->...most existing C programs exit with a code of 0, 1, or 2 and that >->0=success, nonzero=failure is a common convention): > >What does "2" commonly mean? "Other kind of error?" ... The usual custom is that 0 means success, 1 means failure, 2 means it was invoked improperly (e.g. unknown option) and hence didn't even try. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu