| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Many functions in the GNU C library detect and report error conditions, and sometimes your programs need to check for these error conditions. For example, when you open an input file, you should verify that the file was actually opened correctly, and print an error message or take other appropriate action if the call to the library function failed.
This chapter describes how the error reporting facility works. Your program should include the header file `errno.h' to use this facility.
2.1 Checking for Errors How errors are reported by library functions. 2.2 Error Codes Error code macros; all of these expand into integer constant values. 2.3 Error Messages Mapping error codes onto error messages.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Most library functions return a special value to indicate that they have
failed. The special value is typically -1, a null pointer, or a
constant such as EOF that is defined for that purpose. But this
return value tells you only that an error has occurred. To find out
what kind of error it was, you need to look at the error code stored in the
variable errno. This variable is declared in the header file
`errno.h'.
errno contains the system error number. You can
change the value of errno.
Since errno is declared volatile, it might be changed
asynchronously by a signal handler; see 24.4 Defining Signal Handlers.
However, a properly written signal handler saves and restores the value
of errno, so you generally do not need to worry about this
possibility except when writing signal handlers.
The initial value of errno at program startup is zero. Many
library functions are guaranteed to set it to certain nonzero values
when they encounter certain kinds of errors. These error conditions are
listed for each function. These functions do not change errno
when they succeed; thus, the value of errno after a successful
call is not necessarily zero, and you should not use errno to
determine whether a call failed. The proper way to do that is
documented for each function. If the call failed, you can
examine errno.
Many library functions can set errno to a nonzero value as a
result of calling other library functions which might fail. You should
assume that any library function might alter errno when the
function returns an error.
Portability Note: ISO C specifies errno as a
"modifiable lvalue" rather than as a variable, permitting it to be
implemented as a macro. For example, its expansion might involve a
function call, like *_errno (). In fact, that is what it is
on the GNU system itself. The GNU library, on non-GNU systems, does
whatever is right for the particular system.
There are a few library functions, like sqrt and atan,
that return a perfectly legitimate value in case of an error, but also
set errno. For these functions, if you want to check to see
whether an error occurred, the recommended method is to set errno
to zero before calling the function, and then check its value afterward.
All the error codes have symbolic names; they are macros defined in `errno.h'. The names start with `E' and an upper-case letter or digit; you should consider names of this form to be reserved names. See section 1.3.3 Reserved Names.
The error code values are all positive integers and are all distinct,
with one exception: EWOULDBLOCK and EAGAIN are the same.
Since the values are distinct, you can use them as labels in a
switch statement; just don't use both EWOULDBLOCK and
EAGAIN. Your program should not make any other assumptions about
the specific values of these symbolic constants.
The value of errno doesn't necessarily have to correspond to any
of these macros, since some library functions might return other error
codes of their own for other situations. The only values that are
guaranteed to be meaningful for a particular library function are the
ones that this manual lists for that function.
On non-GNU systems, almost any system call can return EFAULT if
it is given an invalid pointer as an argument. Since this could only
happen as a result of a bug in your program, and since it will not
happen on the GNU system, we have saved space by not mentioning
EFAULT in the descriptions of individual functions.
In some Unix systems, many system calls can also return EFAULT if
given as an argument a pointer into the stack, and the kernel for some
obscure reason fails in its attempt to extend the stack. If this ever
happens, you should probably try using statically or dynamically
allocated memory instead of stack memory on that system.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The error code macros are defined in the header file `errno.h'. All of them expand into integer constant values. Some of these error codes can't occur on the GNU system, but they can occur using the GNU library on other systems.
You can choose to have functions resume after a signal that is handled,
rather than failing with EINTR; see 24.5 Primitives Interrupted by Signals.
exec functions (see section 26.5 Executing a File) occupy too much memory space. This condition never arises in the
GNU system.
exec functions; see 26.5 Executing a File.
link (see section 14.4 Hard Links) but
also when you rename a file with rename (see section 14.7 Renaming Files).
In BSD and GNU, the number of open files is controlled by a resource
limit that can usually be increased. If you get this error, you might
want to increase the RLIMIT_NOFILE limit or make it unlimited;
see section 22.2 Limiting Resource Usage.
rename can cause this error if the file being renamed already has
as many links as it can take (see section 14.7 Renaming Files).
SIGPIPE signal; this signal terminates the program if not handled
or blocked. Thus, your program will never actually see EPIPE
unless it has handled or blocked SIGPIPE.
EWOULDBLOCK is another name for EAGAIN;
they are always the same in the GNU C library.
This error can happen in a few different situations:
select to find out
when the operation will be possible; see section 13.8 Waiting for Input or Output.
Portability Note: In many older Unix systems, this condition
was indicated by EWOULDBLOCK, which was a distinct error code
different from EAGAIN. To make your program portable, you should
check for both codes and treat them the same.
fork
can return this error. It indicates that the shortage is expected to
pass, so your program can try the call again later and it may succeed.
It is probably a good idea to delay for a few seconds before trying it
again, to allow time for other processes to release scarce resources.
Such shortages are usually fairly serious and affect the whole system,
so usually an interactive program should report the error to the user
and return to its command loop.
EAGAIN (above).
The values are always the same, on every operating system.
C libraries in many older Unix systems have EWOULDBLOCK as a
separate error code.
connect; see section 16.9.1 Making a Connection) never return
EAGAIN. Instead, they return EINPROGRESS to indicate that
the operation has begun and will take some time. Attempts to manipulate
the object before the call completes return EALREADY. You can
use the select function to find out when the pending operation
has completed; see section 13.8 Waiting for Input or Output.
ENOMEM; you may get one or the
other from network operations.
EDESTADDRREQ instead.
connect.
PATH_MAX; see section 31.6 Limits on File System Capacity) or host name too long (in gethostname or
sethostname; see section 30.1 Host Identification).
fork. See section 22.2 Limiting Resource Usage, for details on
the RLIMIT_NPROC limit.
On some systems chmod returns this error if you try to set the
sticky bit on a non-directory file; see section 14.9.7 Assigning File Permissions.
ENOSYS unless you
install a new version of the C library or the operating system.
If the entire function is not available at all in the implementation,
it returns ENOSYS instead.
term protocol return
this error for certain operations when the caller is not in the
foreground process group of the terminal. Users do not usually see this
error because functions such as read and write translate
it into a SIGTTIN or SIGTTOU signal. See section 27. Job Control,
for information on process groups and these signals.
They are not yet documented.}
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The library has functions and variables designed to make it easy for
your program to report informative error messages in the customary
format about the failure of a library call. The functions
strerror and perror give you the standard error message
for a given error code; the variable
program_invocation_short_name gives you convenient access to the
name of the program that encountered the error.
strerror function maps the error code (see section 2.1 Checking for Errors) specified by the errnum argument to a descriptive error
message string. The return value is a pointer to this string.
The value errnum normally comes from the variable errno.
You should not modify the string returned by strerror. Also, if
you make subsequent calls to strerror, the string might be
overwritten. (But it's guaranteed that no library function ever calls
strerror behind your back.)
The function strerror is declared in `string.h'.
strerror_r function works like strerror but instead of
returning the error message in a statically allocated buffer shared by
all threads in the process, it returns a private copy for the
thread. This might be either some permanent global data or a message
string in the user supplied buffer starting at buf with the
length of n bytes.
At most n characters are written (including the NUL byte) so it is up to the user to select the buffer large enough.
This function should always be used in multi-threaded programs since
there is no way to guarantee the string returned by strerror
really belongs to the last call of the current thread.
This function strerror_r is a GNU extension and it is declared in
`string.h'.
stderr;
see 12.2 Standard Streams.
If you call perror with a message that is either a null
pointer or an empty string, perror just prints the error message
corresponding to errno, adding a trailing newline.
If you supply a non-null message argument, then perror
prefixes its output with this string. It adds a colon and a space
character to separate the message from the error string corresponding
to errno.
The function perror is declared in `stdio.h'.
strerror and perror produce the exact same message for any
given error code; the precise text varies from system to system. On the
GNU system, the messages are fairly short; there are no multi-line
messages or embedded newlines. Each error message begins with a capital
letter and does not include any terminating punctuation.
Compatibility Note: The strerror function is a new
feature of ISO C. Many older C systems do not support this function
yet.
Many programs that don't read input from the terminal are designed to
exit if any system call fails. By convention, the error message from
such a program should start with the program's name, sans directories.
You can find that name in the variable
program_invocation_short_name; the full file name is stored the
variable program_invocation_name.
argv[0]. Note
that this is not necessarily a useful file name; often it contains no
directory names. See section 25.1 Program Arguments.
program_invocation_name minus
everything up to the last slash, if any.)
The library initialization code sets up both of these variables before
calling main.
Portability Note: These two variables are GNU extensions. If
you want your program to work with non-GNU libraries, you must save the
value of argv[0] in main, and then strip off the directory
names yourself. We added these extensions to make it possible to write
self-contained error-reporting subroutines that require no explicit
cooperation from main.
Here is an example showing how to handle failure to open a file
correctly. The function open_sesame tries to open the named file
for reading and returns a stream if successful. The fopen
library function returns a null pointer if it couldn't open the file for
some reason. In that situation, open_sesame constructs an
appropriate error message using the strerror function, and
terminates the program. If we were going to make some other library
calls before passing the error code to strerror, we'd have to
save it in a local variable instead, because those other library
functions might overwrite errno in the meantime.
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
FILE *
open_sesame (char *name)
{
FILE *stream;
errno = 0;
stream = fopen (name, "r");
if (stream == NULL)
{
fprintf (stderr, "%s: Couldn't open file %s; %s\n",
program_invocation_short_name, name, strerror (errno));
exit (EXIT_FAILURE);
}
else
return stream;
}
|
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |