Determining the Reason for Failure

The foregoing discussion identifies most function calls as returning an indication of

• success

• failure

• in rare cases, no information

Once you have discovered that the function call has failed, you need to know why. For example, the UNIX make(1) command needs to know from open(2) when it fails that

• It was unable to open makefile because it did not exist.

• It lacked the permissions necessary to open makefile for reading.

The reason for the failure might have a bearing on the action taken by the command. For example, if it finds that file makefile does not exist, make(1) tries to open the file Makefile instead. However, when it discovers that it lacks permissions to open file makefile, some implementations of the make(1) command report this as an error to the user. See the following Note for variations on this theme by the different UNIX platforms tested.

The nature of a failure is clearly important to the programmer of any software or utility program. The error-reporting mechanism that early developers of UNIX chose was the special external integer variable named errno. Whenever a function call returned a failure indication, it would first assign a reason code for the failure to the external errno variable. The calling program could then examine this external variable if it cared to know the reason for the failure. When the function returned a successful indication (or "no information" indication), the value of errno was left unchanged.

This mechanism was suitable for early versions of UNIX. However, this older method has limitations. To remove the inherent limitations of the errno variable, its definition has changed somewhat in modern versions of UNIX. If it is applied correctly, this change is transparent to you as a programmer.