In programming languages without structured exception handling (e.g. in the C programming language), error codes are often stored in global variables with names such as errno. Error codes are typically identified by number, each indicating a specific error condition. In an application that uses error codes, each function typically defines one return code to indicate a general failure. Upon receipt of that general failure return code, the programmer can check the value stored in the global error code to determine the condition that caused the function to fail. For example, to indicate that an attempt to open a file failed, a function may set the global error code to indicate the cause of the failure and return an invalid file handle. The following sample shows how the error code can be used to explain the cause of the error:
Since error codes are typically global variables, they can be read or written from any portion of the program. As with other global variables, that ease of access can be a source of problems in a multithreaded environment, since the process global variables could be set by more than one thread, causing a race condition. To fix this problem, POSIX defines errno to be a thread-local variable.
Error codes and exception handling
Error codes are slowly disappearing from the programmer's environment as modern object orientedcomputer languages replace them with exceptions. Exceptions have the advantage of being handled with explicit blocks of code, separate from the rest of the code. While it is considered poor practice in methodologies that use error codes and return codes to indicate failure, programmers often neglect to check return values for error conditions. That negligence can cause undesirable effects, as ignored error conditions often cause more severe problems later in the program. Exceptions are implemented in such a way as to separate the error handling code from the rest of the code. Separating the error handling code from the normal logic makes programs easier to write and understand, since one block of error handling code can service errors from any number of function calls. Exception handling also makes the code more readable than implementations with error codes, since exception handling does not disrupt the flow of the code with frequent checks for error conditions.
A common coding error
If you're trying to run a fairly old program on systems with a recent libc, you can encounter the following situations depending on the version :
The program runs but gives a warning
Incorrectly built binary which accesses errno or h_errno directly. Needs to be fixed.
The program does not run giving error
symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference
errno is defined by the ISO C standard to be a modifiable lvalue of type int, and must not be explicitly declared.
It was common in traditional C to declare errno manually (i.e., extern int errno) instead of including . It will not work with modern versions of the C library. However, on (very) old Unix systems, there may be no and the declaration is needed.
In such situations, the source code must be modified to replace all extern int errno lines with a single include: