1

Assume the following C snippet showing a piece of error handling:

#include <sysexits.h> #include <stdio.h> … int main(int argc, char argv*[]) { int retval=0; … if(3!=argc) { /* wrong number of arguments */ retval |= EX_USAGE; const int fprintf_retval = fprintf(stderr, "Bad syntax.\n"); if (0>=fprintf_retval) retval |= … Hmm … ; } … return retval; }

Which error constant from sysexits.h should be placed instead of “… Hmm …”? We can say EX_OSERR (a failure to print an error message shows that something is off, though not necessarily deep in the operating system), or EX_IOERR (it's an output error, though not necessarily into a file), or EX_SOFTWARE (fairly general, but the reason for a failure to print an error typically lies outside the C program, and the error might relate to the operating system). Based only on the comments in sysexits.h, neither of the three constants fits perfectly. So what's the convention?

EDIT: In the scope of this question, we assume that the programmer does want to discern between certain kinds of errors via the exit code, and that more than one error can occur.

Improve this question
12
  • well, on a GNU system, echo returns 1, and grep returns 2, same as for other errors (since for grep, 1 means a succesful run with no match found). sysexits.h defines exit codes starting at 64 on both Ubuntu and FreeBSD and I think I've never seen a program return any such. Though it looks like that's from the BSDs, and I haven't really used them at all. Perhaps the existing utilities that do use the custom would work as a reference. Commented Jul 24 at 9:14
  • anyway, are you sure you should be using |= there to begin with? I.e. that the values form a bit map? Also, this has nothing to do with Linux as such Commented Jul 24 at 9:15
  • @ilkkachu Issuing grep foo 2>> /nonexistent_file as a nonroot, regular user yields exit code 1 on my system. We use “bitwise or” as there may be multiple errors. Say, a scanning program accepts two arguments: the scanner name and the output-file name. The first error might be a wrong scanner name, and the second that the output-file name has not been supplied. Of course, you have 8 bits only, so only 7 possible classes of errors (as the upper bit is reserved for signals), and sysexits.h takes 5 bits already, so you have only 7-5=2 bits left at your pleasure. Still, better than nothing. Commented Jul 24 at 9:39
  • @ilkkachu As for Linux vs. Unices in general, my hope was that someone says how to pass more than 8 bits as an exit code or with an exit code specifically in Linux. Commented Jul 24 at 9:41
  • @user743115 how to pass more than 8 bits as an exit code or with an exit code Per POSIX, the parent process can get the full value in a SIGCHLD signal handler: "The exit value in si_status shall be equal to the full exit value (that is, the value passed to _exit(), _Exit(), or exit(), or returned from main()); it shall not be limited to the least significant eight bits of the value." I don't believe Linux supports that, however Commented Jul 24 at 10:06

1 Answer 1

Reset to default
3

I'd go with EXIT_FAILURE.

For the most part, it does not matter as long as the exit code is nonzero -- anyone calling the program must expect a lot of other error codes, like "failed to write to output and was killed by SIGPIPE", so exact error codes are used only for conditions where a calling shell script might want to react to this particular condition in a different way.

A lot of error handling systems make a distinction between errors that can be handled, and ones that we just give up on receiving, e.g. Java has a class RuntimeException for "things that can happen anytime", and C++ has runtime_error and logic_error as the only direct descendants of the exception class to make the same distinction.

I would categorize the inability to write an error message as one of these cases that can't be rectified by software, so we just bail out with a generic error.

Improve this answer
1
  • Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on Unix & Linux Meta, or in Unix & Linux Chat. Comments continuing discussion may be removed. Commented Jul 29 at 19:52

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.