Re: [PATCH 1/6] fix ambiguous errno treating after mktime()

[Roland Dowdeswell <elric%imrryr.org@localhost>]

On 1219904761 seconds since the Beginning of the UNIX epoch
David Holland wrote:
>
>On Wed, Aug 27, 2008 at 10:12:48PM +0100, David Laight wrote:
> > It is my recollection that errno is only well defined after a function
> > (that sets errno) returns -1 and may be changed even if such a function
> > succeeds.
>
>Historic practice is that succeeding functions do not clear errno to
>0. The intent of this was/is to preserve the previous errno value, so
>code like
>
>   if (read(fd, buf, len < 0)) {
>      close(fd);
>      perror("read");
>      exit(1);
>   }
>
>would behave as intended in the common case.
>
>The principle of least surprise suggests that functions more complex
>than close() should nonetheless behave the same way, and not clobber
>errno on success merely because of some transient internal failure
>occuring in some hidden subsystem the caller doesn't know exists.
>After all, the simplicity of close() with respect to errno is an
>accident of where the user/kernel boundary happens to be and not an
>inherent property of programming in C.

Our man pages certainly agree with this interpretation at least for
system calls:

     When a system call detects an error, it returns an integer
     value indicat- ing failure (usually -1) and sets the variable
     errno accordingly.  (This allows interpretation of the failure
     on receiving a -1 and to take action accordingly.)  Successful
     calls never set errno; once set, it remains until another
     error occurs.  It should only be examined after an error.

                                                from man 2 intro

Given that system behaviour may change over time, it falls upon
libraries to ensure that errno is preserved.  I.e. there is no real
way of knowing a priori if a random libc function will make a system
call and whether or not a system call is invoked may change over
time.

That said, close(2) can in fact return an error and set errno if
you are using AFS and so the code example that you gave is incorrect.
Applications must not assume that errno has not been reset after
a system call is invoked without checking the return code of said
system call.

>So I think in general library functions that try to handle errno in a
>meaningful way should avoid trashing it arbitrarily.
>
>This is particularly true of library functions whose error signaling
>is broken, which includes but is not limited to strto*.
>
>-- 
>David A. Holland
>dholland%netbsd.org@localhost
>

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/