NetBSD Problem Report #41567

From www@NetBSD.org  Wed Jun 10 08:11:53 2009
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id A384963C235
	for <gnats-bugs@gnats.netbsd.org>; Wed, 10 Jun 2009 08:11:53 +0000 (UTC)
Message-Id: <20090610081148.3EF3563BF62@www.NetBSD.org>
Date: Wed, 10 Jun 2009 08:11:48 +0000 (UTC)
From: ekamperi@gmail.com
Reply-To: ekamperi@gmail.com
To: gnats-bugs@NetBSD.org
Subject: posix_memalign(3) taints errno when it shouldn't.
X-Send-Pr-Version: www-1.0

>Number:         41567
>Category:       lib
>Synopsis:       posix_memalign(3) taints errno when it shouldn't.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          closed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Jun 10 08:15:00 +0000 2009
>Closed-Date:    Tue Aug 18 15:14:15 +0000 2009
>Last-Modified:  Tue Aug 18 15:14:15 +0000 2009
>Originator:     Stathis Kamperis
>Release:        NetBSD 5.0_STABLE
>Organization:
Aristotle University of Thessaloniki
>Environment:
NetBSD voyager 5.0_STABLE NetBSD 5.0_STABLE (MYGENERIC) #4: Sat May 23 15:45:44 EEST 2009  root@voyager:/usr/obj/sys/arch/i386/compile/MYGENERIC i386

>Description:
posix_memalign(3) is supposed to return an error value, not set the errno variable.
>How-To-Repeat:
#include <assert.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
        void *ptr;
        int old_errno;

        /*
         * Save old errno value to see if posix_memalign() messes with it
         * (error codes are supposed to be returned, not be saved to errno).
         */
        old_errno = errno;

        /* Alignment parameter is not a power of 2. */
        assert(posix_memalign(&ptr, 1 + (sizeof(void *) << 5), 100) == EINVAL);
        assert(old_errno == errno);

        printf("passed\n");

        return (EXIT_SUCCESS);
}

>Fix:

>Release-Note:

>Audit-Trail:
From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org
Subject: re: lib/41567: posix_memalign(3) taints errno when it shouldn't.
Date: Wed, 10 Jun 2009 18:36:53 +1000

 what says that errno must not be touched?  the return value is already
 correct, and the documentation i read does not say it *must* not touch
 errno.  this is not a problem.


 .mrg.

From: Stathis Kamperis <ekamperi@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/41567
Date: Wed, 10 Jun 2009 12:02:50 +0300

 Strictly speaking the spec doesn't say that the errno shouldn't be
 touched. Though, usually, when errno is expected to be set, it is
 explicitly mentioned. Moreover, what's the use of returning an error
 code and setting errno at the same time ? As far as I know, glibc
 doesn't set errno, nor DragonFly's libc. On the other hand, sun OS
 5.10 and NetBSD do. Again, this is not a bug, but I think it would be
 nice to have. At the very least it should be documented in
 posix_memalign(3) that the function sets errno.

 Cheers,
 Stathis

State-Changed-From-To: open->analyzed
State-Changed-By: kleink@NetBSD.org
State-Changed-When: Sun, 19 Jul 2009 07:27:04 +0000
State-Changed-Why:
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.

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.

In any case, "nice to have" in this case boils down to
encouragement of non-portable use of the interface.


From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@netbsd.org, netbsd-bugs@netbsd.org,
	gnats-admin@netbsd.org, kleink@NetBSD.org, ekamperi@gmail.com
Subject: Re: lib/41567 (posix_memalign(3) taints errno when it shouldn't.)
Date: Sun, 19 Jul 2009 18:11:25 +0000

 On Sun, Jul 19, 2009 at 07:27:05AM +0000, kleink@NetBSD.org 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

From: Klaus Klein <kleink@kleink.org>
To: David Holland <dholland-bugs@netbsd.org>
Cc: gnats-bugs@NetBSD.org, lib-bug-people@netbsd.org,
	netbsd-bugs@netbsd.org, gnats-admin@netbsd.org, kleink@NetBSD.org,
	ekamperi@gmail.com
Subject: Re: lib/41567 (posix_memalign(3) taints errno when it shouldn't.)
Date: Mon, 20 Jul 2009 22:44:19 +0200

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

From: "David A. Holland" <dholland@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/41567 CVS commit: src/lib/libc/sys
Date: Thu, 23 Jul 2009 02:31:56 +0000

 Module Name:	src
 Committed By:	dholland
 Date:		Thu Jul 23 02:31:56 UTC 2009

 Modified Files:
 	src/lib/libc/sys: intro.2

 Log Message:
 Mention, along with the behavior of succeeding system calls, the
 normal behavior of succeeding library functions regarding errno.
 (That is, they may leave arbitrary nonzero values in errno.)

 Ok kleink@; related to PR lib/41567 as well as a recent thread on
 tech-userlevel.


 To generate a diff of this commit:
 cvs rdiff -u -r1.52 -r1.53 src/lib/libc/sys/intro.2

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/41567 (posix_memalign(3) taints errno when it shouldn't.)
Date: Thu, 23 Jul 2009 02:55:36 +0000

 On Mon, Jul 20, 2009 at 08:50:08PM +0000, Klaus Klein wrote:
  >> 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:
  >> [snip]
  >  
  >  I like it; please commit!

 Done :-)

 -- 
 David A. Holland
 dholland@netbsd.org

State-Changed-From-To: analyzed->pending-pullups
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Fri, 24 Jul 2009 06:09:16 +0000
State-Changed-Why:
pullup-5 #867, pullup-4 #1340


From: Soren Jacobsen <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/41567 CVS commit: [netbsd-5-0] src/lib/libc/sys
Date: Sun, 26 Jul 2009 18:35:51 +0000

 Module Name:	src
 Committed By:	snj
 Date:		Sun Jul 26 18:35:50 UTC 2009

 Modified Files:
 	src/lib/libc/sys [netbsd-5-0]: intro.2

 Log Message:
 Pull up following revision(s) (requested by dholland in ticket #867):
 	lib/libc/sys/intro.2: revisions 1.53, 1.54
 Mention, along with the behavior of succeeding system calls, the
 normal behavior of succeeding library functions regarding errno.
 (That is, they may leave arbitrary nonzero values in errno.)
 Ok kleink@; related to PR lib/41567 as well as a recent thread on
 tech-userlevel.


 To generate a diff of this commit:
 cvs rdiff -u -r1.49 -r1.49.14.1 src/lib/libc/sys/intro.2

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Soren Jacobsen <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/41567 CVS commit: [netbsd-5] src/lib/libc/sys
Date: Sun, 26 Jul 2009 18:36:44 +0000

 Module Name:	src
 Committed By:	snj
 Date:		Sun Jul 26 18:36:44 UTC 2009

 Modified Files:
 	src/lib/libc/sys [netbsd-5]: intro.2

 Log Message:
 Pull up following revision(s) (requested by dholland in ticket #867):
 	lib/libc/sys/intro.2: revisions 1.53, 1.54
 Mention, along with the behavior of succeeding system calls, the
 normal behavior of succeeding library functions regarding errno.
 (That is, they may leave arbitrary nonzero values in errno.)
 Ok kleink@; related to PR lib/41567 as well as a recent thread on
 tech-userlevel.


 To generate a diff of this commit:
 cvs rdiff -u -r1.49 -r1.49.10.1 src/lib/libc/sys/intro.2

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Manuel Bouyer <bouyer@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/41567 CVS commit: [netbsd-4] src/lib/libc/sys
Date: Tue, 18 Aug 2009 09:53:23 +0000

 Module Name:	src
 Committed By:	bouyer
 Date:		Tue Aug 18 09:53:23 UTC 2009

 Modified Files:
 	src/lib/libc/sys [netbsd-4]: intro.2

 Log Message:
 Pull up following revision(s) (requested by dholland in ticket #1340):
 	lib/libc/sys/intro.2: revision 1.53
 	lib/libc/sys/intro.2: revision 1.54
 Mention, along with the behavior of succeeding system calls, the
 normal behavior of succeeding library functions regarding errno.
 (That is, they may leave arbitrary nonzero values in errno.)
 Ok kleink@; related to PR lib/41567 as well as a recent thread on
 tech-userlevel.
 Bump date for previous.


 To generate a diff of this commit:
 cvs rdiff -u -r1.45 -r1.45.2.1 src/lib/libc/sys/intro.2

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Manuel Bouyer <bouyer@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/41567 CVS commit: [netbsd-4-0] src/lib/libc/sys
Date: Tue, 18 Aug 2009 09:53:28 +0000

 Module Name:	src
 Committed By:	bouyer
 Date:		Tue Aug 18 09:53:28 UTC 2009

 Modified Files:
 	src/lib/libc/sys [netbsd-4-0]: intro.2

 Log Message:
 Pull up following revision(s) (requested by dholland in ticket #1340):
 	lib/libc/sys/intro.2: revision 1.53
 	lib/libc/sys/intro.2: revision 1.54
 Mention, along with the behavior of succeeding system calls, the
 normal behavior of succeeding library functions regarding errno.
 (That is, they may leave arbitrary nonzero values in errno.)
 Ok kleink@; related to PR lib/41567 as well as a recent thread on
 tech-userlevel.
 Bump date for previous.


 To generate a diff of this commit:
 cvs rdiff -u -r1.45 -r1.45.6.1 src/lib/libc/sys/intro.2

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: pending-pullups->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Tue, 18 Aug 2009 15:14:15 +0000
State-Changed-Why:
Pullups complete.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.