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

[Klaus Klein <kleink%kleink.org@localhost>]

On Sun, Jul 19, 2009 at 06:11:25PM +0000, David Holland wrote:
> 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...

That I concede, despite the alignment of POSIX with ISO C; I'd chosen
to quote from the latter as it matches the case for the bug-reported
posix_memalign(3) best.  Anyway, XSH 2.3 (2nd paragraph) still holds.

>  > 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 .

I like it; please commit!