RESEARCH: Exit codes #102

New Issue

2020-04-14T15:31:51+02:00

Kreyren commented

2020-04-14 15:31:51 +02:00

(Migrated from github.com)

Our exit codes may not be standardized and may occupy an exit code already defined by various systems -> Needs to be re-implemented

Check sysexits.h for reference on POSIX exit codes 64~70

255 is not a normal exit status. EXIT_FAILURE is 1, unless you have multiple different error conditions to signal

Some broken code returns exit status 255 because the author wrote "exit(-1)". It's not a pattern that should be emulated

if (fork()) { execv(cmd,args); exit(127); } wait(); // the extern cmd appears to return 127 when in fact the executable could not be invoked

Pick a range like 32 to 63 and define your own meanings, and document them or use 2 for "errors" and 1 for "false"

Seeing 255 as an explicit return code sets off alarm bells for code review

The only case I've seen which legitimately documented using 255 was where its return code was the number of errors, or 255 if more than 254 errors occurred. However that's a rarity, and more often the type of error rather than the quantity is of more interest to the caller.

exit codes actually should not be higher than 127 as any code higher than that means that the process was killed with a signal

by "exit status out of range" they mean "the programmer made a mistake choosing a code", not "you should use this code if your Windows exit code doesn't fit in 0-255"

See https://shapeshed.com/unix-exit-codes/

See less /usr/include/sysexits.h

(Unfortunately EX_OK from that conflicts with EX_OK from flock()

The whole notion of an exit code convention is that you, the programmer, who is writing a program, and wants to DECDIE what exit codes to USE in your OWN PROGRAM, might want to know what codes OTHER PROGRAMMERS have used in THEIR PROGRAMS, so that you can blend into the herd.

The standard C <stdlib.h> (/usr/include/stdlib.h) only mentions EXIT_SUCCESS and EXIT_FAILURE. POSIX provides for an 8-bit exit status, with 0 conventionally being success and anything else a failure. The system() call returns 127 if the program cannot be invoked (as per the example code I gave before). The shell assumes that anything over 127 is reserved for indicating signalling. The common C <sysexits.h> defines EX_USAGE (64) through EX_CONFI
Apart from 0=success, the rest is a matter of convention, and parts of different standards, so i figure it's worth sticking to that unless there's a good reason to choose otherwisee.

One last thing; when choosing numbers, be aware that sometimes the binary patterns are useful; that's why sysexits.h starts at 64 - an even power of 2. It's also why I suggested 32-63 as a suitable "roll your own" range, because the in-range test 32<=x&&x<=63 can be reduced to (x&~31)==32 (Like how network subnet ranges are detected)

You are right to be concerned at the lack of "official" documentation. Most 'nix programmers no longer come through the "learn C and the POSIX system calls" route to programming, so they don't get exposed to these conventions as a matter of course.

Define our own standard?

Our exit codes may not be standardized and may occupy an exit code already defined by various systems -> Needs to be re-implemented Check `sysexits.h` for reference on POSIX exit codes 64~70 > 255 is not a normal exit status. EXIT_FAILURE is 1, unless you have multiple different error conditions to signal > Some broken code returns exit status 255 because the author wrote "exit(-1)". It's not a pattern that should be emulated > if (fork()) { execv(cmd,args); exit(127); } wait(); // the extern cmd appears to return 127 when in fact the executable could not be invoked > Pick a range like 32 to 63 and define your own meanings, and document them or use 2 for "errors" and 1 for "false" > Seeing 255 as an explicit return code sets off alarm bells for code review > The only case I've seen which legitimately documented using 255 was where its return code was the number of errors, or 255 if more than 254 errors occurred. However that's a rarity, and more often the type of error rather than the quantity is of more interest to the caller. > exit codes actually should not be higher than 127 as any code higher than that means that the process was killed with a signal > by "exit status out of range" they mean "the programmer made a mistake choosing a code", not "you should use this code if your Windows exit code doesn't fit in 0-255" See https://shapeshed.com/unix-exit-codes/ See ` less /usr/include/sysexits.h` > (Unfortunately EX_OK from that conflicts with EX_OK from flock() > The whole notion of an exit code convention is that you, the programmer, who is writing a program, and wants to DECDIE what exit codes to USE in your OWN PROGRAM, might want to know what codes OTHER PROGRAMMERS have used in THEIR PROGRAMS, so that you can blend into the herd. > The standard C <stdlib.h> (/usr/include/stdlib.h) only mentions EXIT_SUCCESS and EXIT_FAILURE. POSIX provides for an 8-bit exit status, with 0 conventionally being success and anything else a failure. The system() call returns 127 if the program cannot be invoked (as per the example code I gave before). The shell assumes that anything over 127 is reserved for indicating signalling. The common C <sysexits.h> defines EX_USAGE (64) through EX_CONFI > Apart from 0=success, the rest is a matter of convention, and parts of different standards, so i figure it's worth sticking to that unless there's a good reason to choose otherwisee. > One last thing; when choosing numbers, be aware that sometimes the binary patterns are useful; that's why sysexits.h starts at 64 - an even power of 2. It's also why I suggested 32-63 as a suitable "roll your own" range, because the in-range test 32<=x&&x<=63 can be reduced to (x&~31)==32 (Like how network subnet ranges are detected) > You are right to be concerned at the lack of "official" documentation. Most 'nix programmers no longer come through the "learn C and the POSIX system calls" route to programming, so they don't get exposed to these conventions as a matter of course. - Define our own standard?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: kreyren/Zernit#102