On Haiku alpha 2, test-unsetenv.c passed in isolation with just
system headers, but failed when libgnu and replacement headers
were in use. Why? Because putenv("a") fails to remove "a=..."
from the environment, but the gnulib rpl_putenv works by
assigning to environ. Apparently, Haiku is doing some funky
caching issues, and correctly removes all vestiges of environment
duplicates when Haiku is in charge, but not after assigning to
environ forces Haiku to rebuild its cache.
The m4 change is sufficient to detect Haiku's oddities, and the
existing replacement then passes just fine.
* m4/setenv.m4 (gl_FUNC_UNSETENV): Also detect Haiku issue.
* doc/posix-functions/unsetenv.texi (unsetenv): Document it.
Signed-off-by: Eric Blake <eblake@redhat.com>
* lib/stdlib.in.h (setenv): Test HAVE_DECL_UNSETENV, not HAVE_UNSETENV.
* m4/setenv.m4 (gl_FUNC_UNSETENV): Test whether unsetenv is declared.
Don't set HAVE_UNSETENV. In the test program, set _BSD.
* m4/stdlib_h.m4 (gl_STDLIB_H_DEFAULTS): Initialize HAVE_DECL_UNSETENV,
not HAVE_UNSETENV.
* modules/stdlib (Makefile.am): Substitute HAVE_DECL_UNSETENV, not
HAVE_UNSETENV.
* doc/posix-functions/unsetenv.texi: Mention the OSF/1 5.1 problem.
* m4/setenv.m4 (gl_FUNC_UNSETENV): Check for OpenBSD bug.
* doc/posix-functions/unsetenv.texi (unsetenv): Update
documentation.
Reported by Jim Meyering.
Signed-off-by: Eric Blake <eblake@redhat.com>
Requiring that {un,}setenv gracefully reject NULL is just a waste
of processing power; POSIX agreed to this argument in
http://austingroupbugs.net/view.php?id=185
so we no longer worry whether a native implementation handles NULL.
* m4/setenv.m4 (gl_FUNC_SETENV_SEPARATE): Test handling of "" but
not NULL.
* tests/test-setenv.c (main): Relax test.
* tests/test-unsetenv.c (main): Likewise.
* doc/posix-functions/setenv.texi (setenv): Document this.
* doc/posix-functions/unsetenv.texi (unsetenv): Likewise.
Signed-off-by: Eric Blake <ebb9@byu.net>
POSIX requires setenv(NULL,"",0), setenv("a=b","",0),
unsetenv(NULL), and unsetenv("a=b") to fail with EINVAL, but
many BSD implementations lack validation. The gnulib
replacement for void unsetenv did not do validation, and the
replacement for setenv was out of sync with glibc. Also, some
BSD implementations of setenv("a","==",1) eat the leading '='.
See also some recent Austin Group interpretations on environ:
http://austingroupbugs.net/view.php?id=167http://austingroupbugs.net/view.php?id=185
* lib/setenv.c (setenv) [!HAVE_SETENV]: Resync from glibc.
(setenv) [HAVE_SETENV]: Work around bugs.
* lib/unsetenv.c (unsetenv) [HAVE_UNSETENV]: Work around bugs.
* m4/setenv.m4 (gl_FUNC_SETENV_SEPARATE, gl_FUNC_UNSETENV): Check
for bugs.
(gl_FUNC_SETENV): Write in terms of gl_FUNC_SETENV_SEPARATE.
* m4/environ.m4 (gl_ENVIRON): Avoid expand-before-require.
* m4/stdlib_h.m4 (gl_STDLIB_H_DEFAULTS): Update defaults.
* modules/stdlib (Makefile.am): Update substitutions.
* lib/stdlib.in.h (setenv, unsetenv): Update prototypes.
* doc/posix-functions/setenv.texi (setenv): Document the bugs.
* doc/posix-functions/unsetenv.texi (unsetenv): Likewise.
* modules/setenv-tests: New test.
* modules/unsetenv-tests: Likewise.
* tests/test-setenv.c: New file.
* tests/test-unsetenv.c: Likewise.
Signed-off-by: Eric Blake <ebb9@byu.net>
