| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Not because I admit they are technically wrong and not because of bug
reports (I receive nothing). But because I surprisingly meets so
strong opposition and resistance so lost any desire to continue that.
Anyone who interested in POSIX can dig out what changes and how
through cvs diffs.
|
|
|
|
| |
Suggested by: Henrik Brix Andersen <henrik@brixandersen.dk>
|
|
|
|
|
| |
"so altering the argument shall change the environment."
into putenv description.
|
|
|
|
|
|
|
|
|
|
|
| |
(also IEEE Std 1003.1-2001)
The specs explicitly says that altering passed string
should change the environment, i.e. putenv() directly puts its arg
into environment (unlike setenv() which just copies it there).
It means that putenv() can't be implemented via setenv()
(like we have before) at all. Putenv() value lives (allows modifying)
up to the next putenv() or setenv() call.
|
|
|
|
|
|
|
|
|
| |
compatibility with the different environment conventions" (man page).
With the standards, we don't have them different anymore and
IEEE Std 1003.1-2001 says that
"The values that the environment variables may be assigned are not
restricted except that they are considered to end with a null byte"
|
|
|
|
|
|
|
|
|
| |
Issue 6 (also IEEE Std 1003.1-2001) in following areas:
args, return, errors.
Putenv still needs rewriting because specs explicitly says that
altering passed string later should change the environment (currently we
copy the string so can't provide that).
|
|
|
|
|
|
| |
clause.
# If I've done so improperly on a file, please let me know.
|
|
|
|
|
| |
PR: 60544
Reviewed by: ru
|
|
|
|
|
|
|
|
| |
getobjformat.3: "takes precedence over" is not an envrionment variable.
PR: 75545
Submitted by: n-kogane@syd.odn.ne.jp
MFC after: 3 days
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
under the RETURN VALUES section so it is consistent with others.
Cleanup the return value text for getenv(3) a little while I am here.
PR: docs/58033
MFC after: 3 days
|
| |
|
| |
|
|
|
|
| |
Inspired by comment from: dd
|
|
|
|
| |
Submitted by: yar
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
More libraries manpages updates following.
|
|
|
|
|
|
| |
for getenv()/putenv().
PR: 10341 5604
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
track.
The $Id$ line is normally at the bottom of the main comment block in the
man page, separated from the rest of the manpage by an empty comment,
like so;
.\" $Id$
.\"
If the immediately preceding comment is a @(#) format ID marker than the
the $Id$ will line up underneath it with no intervening blank lines.
Otherwise, an additional blank line is inserted.
Approved by: bde
|
|
|