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

[David Holland <dholland-tech%netbsd.org@localhost>]

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.

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