Re: lib/41567 (posix_memalign(3) taints errno when it shouldn't.)

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

On Sun, Jul 19, 2009 at 07:27:05AM +0000, kleink%NetBSD.org@localhost wrote:
 > The standard (ISO/IEC 9899:1999, 7.5#3) is clear on this issue:
 > 
 >   The value of errno may be set to nonzero by a library
 >   function call whether or not there is an error, provided
 >   the use of errno is not documented in the description
 >   of the function in this International Standard.

What POSIX says (which isn't the same) would be more pertinent...

 > Documenting this in posix_memalign(3) alone would be taking
 > the wrong road, too; this is a general concept which fits
 > errno(2) better, with the issue of errno(2) currently
 > addressing the behavior if system calls only.

Documenting that things may trash errno is not quite the same as
documenting whether a function explicitly sets a valid errno on an
error return if it does so.

In this case though, on the latter point I think silence is probably
better as the behavior is nonportable.

On the former point, how about this:

Index: intro.2
===================================================================
RCS file: /cvsroot/src/lib/libc/sys/intro.2,v
retrieving revision 1.52
diff -u -r1.52 intro.2
--- intro.2     2 Jun 2009 13:15:41 -0000       1.52
+++ intro.2     19 Jul 2009 18:07:51 -0000
@@ -64,10 +64,17 @@
 Successful calls never set
 .Va errno ;
 once set, it remains until another error occurs.
-It should only be examined after an error.
-Note that a number of system calls overload the meanings of these
-error numbers, and that the meanings must be interpreted according
-to the type and circumstances of the call.
+It should only be examined after an error has been reported, because
+otherwise a leftover value from some previous error may be found
+instead.
+.Po
+Many library functions that are not system calls also set
+.Va errno
+on return, in the same fashion.
+In these cases a nonzero value may be left in
+.Va errno
+even upon successful return if some internal action failed.
+.Pc
 .Pp
 The manual page for each system call will list some of the common
 errno codes that system call can return, but that should not be
@@ -78,6 +85,10 @@
 a more specification-like manner would take more resources than
 this project has available.
 .Pp
+Note also that a number of system calls overload the meanings of these
+error numbers, and that in these cases the meanings must be
+interpreted according to the type and circumstances of the call.
+.Pp
 The following is a complete list of the errors and their
 names as given in
 .Aq Pa errno.h .

-- 
David A. Holland
dholland%netbsd.org@localhost