[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: putenv documentation
From: |
Paul Eggert |
Subject: |
Re: putenv documentation |
Date: |
Tue, 28 Sep 2004 10:26:10 -0700 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
address@hidden (Michael Wardle) writes:
> Is somebody able to verify this statement, or perhaps rephrase or delete
> it as appropriate?
Thanks for reporting that. I installed this fix:
2004-09-28 Paul Eggert <address@hidden>
* doc/autoconf.texi (Function Portability): Fix misdescription
of putenv. Problem reported by Michael Wardle.
Index: autoconf.texi
===================================================================
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.833
retrieving revision 1.834
diff -p -u -r1.833 -r1.834
--- autoconf.texi 22 Sep 2004 18:05:01 -0000 1.833
+++ autoconf.texi 28 Sep 2004 17:21:52 -0000 1.834
@@ -3721,14 +3721,18 @@ can be used to insist on address@hidden
@item @code{putenv}
@c @fuindex putenv
@prindex @code{putenv}
+POSIX prefers @code{setenv} to @code{putenv}; among other things,
address@hidden is not required of all POSIX implementations, but
address@hidden is.
+
POSIX specifies that @code{putenv} puts the given string directly in
@code{environ}, but some systems make a copy of it instead (e.g.,
glibc 2.0, or BSD). And when a copy is made, @code{unsetenv} might
not free it, causing a memory leak (e.g., FreeBSD 4).
-POSIX specifies that @code{putenv("FOO")} removes @samp{FOO} from the
-environment, but on some systems (e.g., FreeBSD 4) this is not the
-case and instead @code{unsetenv} must be used.
+On some systems @code{putenv("FOO")} removes @samp{FOO} from the
+environment, but this is not standard usage and it dumps core
+on some systems (e.g., AIX).
On MINGW, a call @code{putenv("FOO=")} removes @samp{FOO} from the
environment, rather than inserting it with an empty value.
@@ -3827,7 +3831,7 @@ strnlen ("foobar", 9) = 6
@prindex @code{unlink}
The @acronym{POSIX} spec says that @code{unlink} causes the given file to be
removed only after there are no more open file handles for it. Not all
-OS's support this behavior though. So even on systems that provide
+OSes support this behavior though. So even on systems that provide
@code{unlink}, you cannot portably assume it is OK to call it on files
that are open. For example, on Windows 9x and ME, such a call would fail;
on DOS it could even lead to file system corruption, as the file might end