Previous: Error Codes, Up: Error Reporting [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.
Preliminary: | MT-Safe | AS-Unsafe heap i18n | AC-Unsafe mem | See POSIX Safety Concepts.
The strerror function maps the error code (see Checking for Errors) specified by the errnum argument to a descriptive error
message string. The string is translated according to the current
locale. 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 or strerror_l, or
the thread that obtained the string exits, the returned pointer will be
invalidated.
As there is no way to restore the previous state after calling
strerror, library code should not call this function because it
may interfere with application use of strerror, invalidating the
string pointer before the application is done using it. Instead,
strerror_r, snprintf with the ‘%m’ or ‘%#m’
specifiers, strerrorname_np, or strerrordesc_np can be
used instead.
The strerror function preserves the value of errno and
cannot fail.
The function strerror is declared in string.h.
Preliminary: | MT-Safe | AS-Unsafe heap i18n | AC-Unsafe mem | See POSIX Safety Concepts.
This function is like strerror, except that the returned string
is translated according to locale (instead of the current locale
used by strerror). Note that calling strerror_l
invalidates the pointer returned by strerror and vice versa.
The function strerror_l is defined by POSIX and is declared in
string.h.
Preliminary: | MT-Safe | AS-Unsafe i18n | AC-Unsafe | See POSIX Safety Concepts.
The following description is for the GNU variant of the function,
used if _GNU_SOURCE is defined. See Feature Test Macros.
The strerror_r function works like strerror but instead of
returning a pointer to a string that is managed by the GNU C Library, it can
use the user supplied buffer starting at buf for storing the
string.
At most n characters are written (including the NUL byte) to buf, so it is up to the user to select a buffer large enough. Whether returned pointer points to the buf array or not depends on the errnum argument. If the result string is not stored in buf, the string will not change for the remaining execution of the program.
The function strerror_r as described above is a GNU extension and
it is declared in string.h. There is a POSIX variant of this
function, described next.
Preliminary: | MT-Safe | AS-Unsafe i18n | AC-Unsafe | See POSIX Safety Concepts.
This variant of the strerror_r function is used if a standard is
selected that includes strerror_r, but _GNU_SOURCE is not
defined. This POSIX variant of the function always writes the error
message to the specified buffer buf of size n bytes.
Upon success, strerror_r returns 0. Two more return values are
used to indicate failure.
EINVAL ¶The errnum argument does not correspond to a known error constant.
ERANGE ¶The buffer size n is not large enough to store the entire error message.
Even if an error is reported, strerror_r still writes as much of
the error message to the output buffer as possible. After a call to
strerror_r, the value of errno is unspecified.
If you want to use the always-copying POSIX semantics of
strerror_r in a program that is potentially compiled with
_GNU_SOURCE defined, you can use snprintf with the
‘%m’ conversion specifier, like this:
int saved_errno = errno; errno = errnum; int ret = snprintf (buf, n, "%m"); errno = saved_errno; if (strerrorname_np (errnum) == NULL) return EINVAL; if (ret >= n) return ERANGE: return 0;
This function is declared in string.h if it is declared at all. It is a POSIX extension.
Preliminary: | MT-Safe race:stderr | AS-Unsafe corrupt i18n heap lock | AC-Unsafe corrupt lock mem fd | See POSIX Safety Concepts.
This function prints an error message to the stream stderr;
see Standard Streams. The orientation of stderr is not
changed.
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.
| MT-Safe | AS-Safe | AC-Safe | See POSIX Safety Concepts.
This function returns the name describing the error errnum or
NULL if there is no known constant with this value (e.g "EINVAL"
for EINVAL). The returned string does not change for the
remaining execution of the program.
This function is a GNU extension, declared in the header file string.h.
| MT-Safe | AS-Safe | AC-Safe | See POSIX Safety Concepts.
This function returns the message describing the error errnum or
NULL if there is no known constant with this value (e.g "Invalid
argument" for EINVAL). Different than strerror the
returned description is not translated, and the returned string does not
change for the remaining execution of the program.
This function is a GNU extension, declared in the header file string.h.
strerror and perror produce the exact same message for any
given error code under the same locale; the precise text varies from
system to system. With the GNU C Library, 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.
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.
This variable’s value is the name that was used to invoke the program
running in the current process. It is the same as argv[0]. Note
that this is not necessarily a useful file name; often it contains no
directory names. See Program Arguments.
This variable is a GNU extension and is declared in errno.h.
This variable’s value is the name that was used to invoke the program
running in the current process, with directory names removed. (That is
to say, it is the same as program_invocation_name minus
everything up to the last slash, if any.)
This variable is a GNU extension and is declared in errno.h.
The library initialization code sets up both of these variables before
calling main.
Portability Note: 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.
#define _GNU_SOURCE
#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;
}
Using perror has the advantage that the function is portable and
available on all systems implementing ISO C. But often the text
perror generates is not what is wanted and there is no way to
extend or change what perror does. The GNU coding standard, for
instance, requires error messages to be preceded by the program name and
programs which read some input files should provide information
about the input file name and the line number in case an error is
encountered while reading the file. For these occasions there are two
functions available which are widely used throughout the GNU project.
These functions are declared in error.h.
Preliminary: | MT-Safe locale | AS-Unsafe corrupt heap i18n | AC-Safe | See POSIX Safety Concepts.
The error function can be used to report general problems during
program execution. The format argument is a format string just
like those given to the printf family of functions. The
arguments required for the format can follow the format parameter.
Just like perror, error also can report an error code in
textual form. But unlike perror the error value is explicitly
passed to the function in the errnum parameter. This eliminates
the problem mentioned above that the error reporting function must be
called immediately after the function causing the error since otherwise
errno might have a different value.
error prints first the program name. If the application
defined a global variable error_print_progname and points it to a
function this function will be called to print the program name.
Otherwise the string from the global variable program_name is
used. The program name is followed by a colon and a space which in turn
is followed by the output produced by the format string. If the
errnum parameter is non-zero the format string output is followed
by a colon and a space, followed by the error message for the error code
errnum. In any case is the output terminated with a newline.
The output is directed to the stderr stream. If the
stderr wasn’t oriented before the call it will be narrow-oriented
afterwards.
The function will return unless the status parameter has a
non-zero value. In this case the function will call exit with
the status value for its parameter and therefore never return. If
error returns, the global variable error_message_count is
incremented by one to keep track of the number of errors reported.
Preliminary: | MT-Unsafe race:error_at_line/error_one_per_line locale | AS-Unsafe corrupt heap i18n | AC-Unsafe corrupt/error_one_per_line | See POSIX Safety Concepts.
The error_at_line function is very similar to the error
function. The only differences are the additional parameters fname
and lineno. The handling of the other parameters is identical to
that of error except that between the program name and the string
generated by the format string additional text is inserted.
Directly following the program name a colon, followed by the file name pointed to by fname, another colon, and the value of lineno is printed.
This additional output of course is meant to be used to locate an error in an input file (like a programming language source code file etc).
If the global variable error_one_per_line is set to a non-zero
value error_at_line will avoid printing consecutive messages for
the same file and line. Repetition which are not directly following
each other are not caught.
Just like error this function only returns if status is
zero. Otherwise exit is called with the non-zero value. If
error returns, the global variable error_message_count is
incremented by one to keep track of the number of errors reported.
As mentioned above, the error and error_at_line functions
can be customized by defining a variable named
error_print_progname.
If the error_print_progname variable is defined to a non-zero
value the function pointed to is called by error or
error_at_line. It is expected to print the program name or do
something similarly useful.
The function is expected to print to the stderr stream and
must be able to handle whatever orientation the stream has.
The variable is global and shared by all threads.
The error_message_count variable is incremented whenever one of
the functions error or error_at_line returns. The
variable is global and shared by all threads.
The error_one_per_line variable influences only
error_at_line. Normally the error_at_line function
creates output for every invocation. If error_one_per_line is
set to a non-zero value error_at_line keeps track of the last
file name and line number for which an error was reported and avoids
directly following messages for the same file and line. This variable
is global and shared by all threads.
A program which read some input file and reports errors in it could look like this:
{
char *line = NULL;
size_t len = 0;
unsigned int lineno = 0;
error_message_count = 0;
while (! feof_unlocked (fp))
{
ssize_t n = getline (&line, &len, fp);
if (n <= 0)
/* End of file or error. */
break;
++lineno;
/* Process the line. */
…
if (Detect error in line)
error_at_line (0, errval, filename, lineno,
"some error text %s", some_variable);
}
if (error_message_count != 0)
error (EXIT_FAILURE, 0, "%u errors found", error_message_count);
}
error and error_at_line are clearly the functions of
choice and enable the programmer to write applications which follow the
GNU coding standard. The GNU C Library additionally contains functions which
are used in BSD for the same purpose. These functions are declared in
err.h. It is generally advised to not use these functions. They
are included only for compatibility.
Preliminary: | MT-Safe locale | AS-Unsafe corrupt heap i18n | AC-Unsafe corrupt lock mem | See POSIX Safety Concepts.
The warn function is roughly equivalent to a call like
error (0, errno, format, the parameters)
except that the global variables error respects and modifies
are not used.
Preliminary: | MT-Safe locale | AS-Unsafe corrupt heap i18n | AC-Unsafe corrupt lock mem | See POSIX Safety Concepts.
The vwarn function is just like warn except that the
parameters for the handling of the format string format are passed
in as a value of type va_list.
Preliminary: | MT-Safe locale | AS-Unsafe corrupt heap | AC-Unsafe corrupt lock mem | See POSIX Safety Concepts.
The warnx function is roughly equivalent to a call like
error (0, 0, format, the parameters)
except that the global variables error respects and modifies
are not used. The difference to warn is that no error number
string is printed.
Preliminary: | MT-Safe locale | AS-Unsafe corrupt heap | AC-Unsafe corrupt lock mem | See POSIX Safety Concepts.
The vwarnx function is just like warnx except that the
parameters for the handling of the format string format are passed
in as a value of type va_list.
Preliminary: | MT-Safe locale | AS-Unsafe corrupt heap i18n | AC-Unsafe corrupt lock mem | See POSIX Safety Concepts.
The err function is roughly equivalent to a call like
error (status, errno, format, the parameters)
except that the global variables error respects and modifies
are not used and that the program is exited even if status is zero.
Preliminary: | MT-Safe locale | AS-Unsafe corrupt heap i18n | AC-Unsafe corrupt lock mem | See POSIX Safety Concepts.
The verr function is just like err except that the
parameters for the handling of the format string format are passed
in as a value of type va_list.
Preliminary: | MT-Safe locale | AS-Unsafe corrupt heap | AC-Unsafe corrupt lock mem | See POSIX Safety Concepts.
The errx function is roughly equivalent to a call like
error (status, 0, format, the parameters)
except that the global variables error respects and modifies
are not used and that the program is exited even if status
is zero. The difference to err is that no error number
string is printed.
Preliminary: | MT-Safe locale | AS-Unsafe corrupt heap | AC-Unsafe corrupt lock mem | See POSIX Safety Concepts.
The verrx function is just like errx except that the
parameters for the handling of the format string format are passed
in as a value of type va_list.
Previous: Error Codes, Up: Error Reporting [Contents][Index]