#2352: POSIX.1 unsetenv returns int
-------------------------------+--------------------------------------------
    Reporter:  donn            |       Owner:                
        Type:  bug             |      Status:  new           
    Priority:  normal          |   Component:  libraries/unix
     Version:  6.8.2           |    Severity:  minor         
    Keywords:                  |    Testcase:                
Architecture:  x86_64 (amd64)  |          Os:  NetBSD        
-------------------------------+--------------------------------------------
 While plenty of C libraries declare void unsetenv(), the POSIX.1003.1
 standard is int unsetenv(), with return values 0 or -1.  In the latter
 case, errno is set to EINVAL, for causes including the present of "=" in
 the value.  Of course this is not of earthshaking importance.

 The following is the autoconf test (just a copy of the same test for
 usleep().)

 --- libraries/unix/configure.ac.dist    2008-06-03 10:39:45.000000000
 -0700
 +++ libraries/unix/configure.ac 2008-06-06 21:43:19.000000000 -0700
 @@ -75,6 +75,19 @@
    ;;
  esac

 +###  POSIX.1003.1 unsetenv returns 0 or -1 (EINVAL), but older
 implementations
 +###  in common use return void.
 +AC_CACHE_CHECK([return type of unsetenv], cv_func_unsetenv_return_type,
 +  [AC_EGREP_HEADER(changequote(<, >)<void[      ]+unsetenv>changequote([,
 ]),
 +                   /usr/include/stdlib.h,
 +                   [cv_func_unsetenv_return_type=void],
 +                   [cv_func_unsetenv_return_type=int])])
 +case "$cv_func_unsetenv_return_type" in
 +  "void" )
 +    AC_DEFINE([UNSETENV_RETURNS_VOID], [1], [Define if stdlib.h declares
 unsetenv to return void.])
 +  ;;
 +esac
 +
  dnl ** sometimes RTLD_NEXT is hidden in #ifdefs we really don't wan to
 set
  AC_MSG_CHECKING(for RTLD_NEXT from dlfcn.h)
  AC_EGREP_CPP(yes,

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2352>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to