[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Incorrect waitpid-handling in buffer.c.

From: Kaz Kylheku
Subject: Re: Incorrect waitpid-handling in buffer.c.
Date: 3 Feb 2003 13:27:06 -0800

Pierre Asselin <pa@panix.com> wrote in message 
> In <mailman.1318.1044159438.21513.bug-cvs@gnu.org> "Johannes 
> =?iso-8859-1?q?Gr=F8dem?=" <johs+n@ifi.uio.no> writes:
> >* Pierre Asselin <pa@panix.com>:
> >> Don't you want to reset errno between syscalls?
> >What for?
> D'oh.  You do test the system call's return value ahead of errno.
> Never mind.

Some library functions are not defined as setting errno, but they
might do so nevertheless. So you do have a point there!

For those functions, the only way to detect that they set errno is to
set it to zero, then invoke the function, detect that it failed (by
some other means than checking errno), and on failure inspect errno.
If it's non-zero, then it holds some error code that probably pertains
to the cause of the error.

ANSI C defines only the EDOM and ERANGE errors (as of C89---maybe
there are more in C99, I don't know offhand). Yet, on many platforms,
errors in the stream library will set errno too---for instance because
the stream library calls the POSIX functions. So in highly portable C
you can do things like:

   errno = 0;

   if ((ch = getc(in)) == EOF) {
      if (ferror(in)) { /* real error, not feof() */
         if (errno != 0) {
            /* have error code */
         } else {
            /* no error code, generic error handling or message */

POSIX doesn't distinguish system calls and library functions; you just
have to read the definition of the function to know whether or how it
affects errno.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]