| 1 | ttn 2004-05-09 |
| 2 | |
| 3 | The exit value of a program returning to the shell on unixoid systems is |
| 4 | typically 0 for success, and non-0 (such as 1) for failure. For vms it is |
| 5 | odd (1,3,5...) for success, even (0,2,4...) for failure. |
| 6 | |
| 7 | This holds from the point of view of the "shell" (in quotes because vms has a |
| 8 | different dispatch model that is not explained further here). |
| 9 | |
| 10 | From the point of view of the program, nowadays stdlib.h on both type of |
| 11 | systems provides macros `EXIT_SUCCESS' and `EXIT_FAILURE' that should DTRT. |
| 12 | |
| 13 | NB: The numerical values of these macros DO NOT need to fulfill the the exit |
| 14 | value requirements outlined in the first paragraph! That is the job of the |
| 15 | `exit' function. Thus, this kind of construct shows misunderstanding: |
| 16 | |
| 17 | #ifdef VMS |
| 18 | exit (1); |
| 19 | #else |
| 20 | exit (0); |
| 21 | #endif |
| 22 | |
| 23 | Values aside from EXIT_SUCCESS and EXIT_FAILURE are tricky. |
| 24 | |
| 25 | |
| 26 | |
| 27 | ttn 2004-05-12 |
| 28 | |
| 29 | Values aside from EXIT_SUCCESS and EXIT_FAILURE can be used to indicate |
| 30 | finer gradations of failure. If this is the only information available |
| 31 | to the caller, clamping such values to EXIT_FAILURE loses information. |
| 32 | If there are other ways to indicate the problem to the caller (such as |
| 33 | a message to stderr) it may be ok to clamp. In all cases, it is the |
| 34 | relationship between the program and its caller that must be examined. |
| 35 | [Insert ZAMM quote here.] |