History log of /freebsd/lib/libc/stdlib/getenv.c (Results 26 – 50 of 68)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: release/8.3.0_cvs, release/8.3.0, release/9.0.0, release/7.4.0_cvs, release/8.2.0_cvs, release/7.4.0, release/8.2.0, release/8.1.0_cvs, release/8.1.0, release/7.3.0_cvs, release/7.3.0
# 1a0fda2b 04-Mar-2010 Dag-Erling Smørgrav <des@FreeBSD.org>

IFH@204581


# 9199c09a 06-Jan-2010 Warner Losh <imp@FreeBSD.org>

Merge from head at r201628.

# This hasn't been tested, and there are at least three bad commits
# that need to be backed out before the branch will be stable again.


# f959b43f 07-Dec-2009 Sean Farley <scf@FreeBSD.org>

Revert behavior change to setenv(), unsetenv() and putenv() until a more
thorough security review has been completed.


# ca7520fe 07-Dec-2009 Sean Farley <scf@FreeBSD.org>

Change the behavior of setenv(), putenv() and unsetenv() to continue parsing
instead of returning an error if a corrupt (not a "name=value" string) entry
in the environ array is detected when (re)-bu

Change the behavior of setenv(), putenv() and unsetenv() to continue parsing
instead of returning an error if a corrupt (not a "name=value" string) entry
in the environ array is detected when (re)-building the internal
environment. This should prevent applications or libraries from
experiencing issues arising from the expectation that these calls will
complete even with corrupt entries. The behavior is now as it was prior to
7.0.

Reviewed by: jilles
MFC after: 1 week

show more ...


# 6da7f71c 07-Dec-2009 Sean Farley <scf@FreeBSD.org>

Improve the comment within getenv() explaining the search order it takes to
find a variable. Include a note that it must not cause the internal
environment to be generated since malloc() depends upo

Improve the comment within getenv() explaining the search order it takes to
find a variable. Include a note that it must not cause the internal
environment to be generated since malloc() depends upon getenv(). To call
malloc() would create a circular dependency.

Recommended by: green
Approved by: jilles
MFC after: 1 week

show more ...


# 56a3273e 01-Dec-2009 Brian Feldman <green@FreeBSD.org>

Temporarily revert the previous change because the linker has been
modified so that it will abort when the environment is bad.


# 20f492f0 01-Dec-2009 Brian Feldman <green@FreeBSD.org>

Do not gratuitously fail *env(3) operations due to corrupt ('='-less)
**environ entries. This puts non-getenv(3) operations in line with
getenv(3) in that bad environ entries do not cause all operat

Do not gratuitously fail *env(3) operations due to corrupt ('='-less)
**environ entries. This puts non-getenv(3) operations in line with
getenv(3) in that bad environ entries do not cause all operations to
fail. There is still some inconsistency in that getenv(3) in the
absence of any environment-modifying operation does not emit corrupt
environ entry warnings.

I also fixed another inconsistency in getenv(3) where updating the
global environ pointer would not be reflected in the return values.
It would have taken an intermediary setenv(3)/putenv(3)/unsetenv(3)
in order to see the change.

show more ...


Revision tags: release/8.0.0_cvs, release/8.0.0, release/7.2.0_cvs, release/7.2.0, release/7.1.0_cvs, release/7.1.0, release/6.4.0_cvs, release/6.4.0
# ee2889cb 04-Aug-2008 Sean Farley <scf@FreeBSD.org>

Restructure and use different variables in the tests that involve
environ[0] to be more obvious that environ is not NULL before environ[0]
is tested. Although I believe the previous code worked, thi

Restructure and use different variables in the tests that involve
environ[0] to be more obvious that environ is not NULL before environ[0]
is tested. Although I believe the previous code worked, this change
improves code maintainability.

Reviewed by: ache
MFC after: 3 days

show more ...


# 3522c38b 02-Aug-2008 Sean Farley <scf@FreeBSD.org>

Detect if the application has cleared the environ variable by setting
the first value (environ[0]) to NULL. This is in addition to the
current detection of environ being replaced, which includes bei

Detect if the application has cleared the environ variable by setting
the first value (environ[0]) to NULL. This is in addition to the
current detection of environ being replaced, which includes being set to
NULL. Without this fix, the environment is not truly wiped, but appears
to be by getenv() until an *env() call is made to alter the enviroment.

This change is necessary to support those applications that use this
method for clearing environ such as Dovecot and Postfix. Applications
such as Sendmail and the base system's env replace environ (already
detected). While neither of these methods are defined by SUSv3, it is
best to support them due to historic reasons and in lieu of a clean,
defined method.

Add extra units tests for clearing environ using four different methods:
1. Set environ to NULL pointer.
2. Set environ[0] to NULL pointer.
3. Set environ to calloc()'d NULL-terminated array.
4. Set environ to static NULL-terminated array.

Noticed by: Timo Sirainen

MFC after: 3 days

show more ...


# 7f08f0dd 28-Feb-2008 Sean Farley <scf@FreeBSD.org>

Replace the use of warnx() with direct output to stderr using _write().
This reduces the size of a statically-linked binary by approximately 100KB
in a trivial "return (0)" test application. readelf

Replace the use of warnx() with direct output to stderr using _write().
This reduces the size of a statically-linked binary by approximately 100KB
in a trivial "return (0)" test application. readelf -S was used to verify
that the .text section was reduced and that using strlen() saved a few
more bytes over using sizeof(). Since the section of code is only called
when environ is corrupt (program bug), I went with fewer bytes over fewer
cycles.

I made minor edits to the submitted patch to make the output resemble
warnx().

Submitted by: kib bz
Approved by: wes (mentor)
MFC after: 5 days

show more ...


Revision tags: release/7.0.0_cvs, release/7.0.0, release/6.3.0_cvs, release/6.3.0
# 8e5b20fa 22-Sep-2007 Sean Farley <scf@FreeBSD.org>

The precision for a string argument in a call to warnx() needs to be cast
to an int to remove the warning from using a size_t variable on 64-bit
platforms.

Submitted by: Xin LI <delphij@FreeBSD.org>

The precision for a string argument in a call to warnx() needs to be cast
to an int to remove the warning from using a size_t variable on 64-bit
platforms.

Submitted by: Xin LI <delphij@FreeBSD.org>
Approved by: wes
Approved by: re (kensmith)

show more ...


# 21c37696 15-Sep-2007 Sean Farley <scf@FreeBSD.org>

Skip rebuilding environ in setenv() only upon reuse of an active variable;
inactive variables should cause a rebuild of environ, otherwise, exec()'d
processes will be missing a variable in environ th

Skip rebuilding environ in setenv() only upon reuse of an active variable;
inactive variables should cause a rebuild of environ, otherwise, exec()'d
processes will be missing a variable in environ that has been unset then
set.

Submitted by: Taku Yamamoto <taku@tackymt.homeip.net>
Reviewed by: ache
Approved by: wes (mentor)
Approved by: re (kensmith)

show more ...


# 9bab2367 21-Jul-2007 Sean Farley <scf@FreeBSD.org>

Added environ-replacement detection. For programs that "clean" (i.e., su)
or replace (i.e., zdump) the environment after a call to setenv(), putenv()
or unsetenv() has been made, a few changes were

Added environ-replacement detection. For programs that "clean" (i.e., su)
or replace (i.e., zdump) the environment after a call to setenv(), putenv()
or unsetenv() has been made, a few changes were made.
- getenv() will return the value from the new environ array.
- setenv() was split into two functions: __setenv() which is most of the
previous setenv() without checks on the name and setenv() which
contains the checks before calling __setenv().
- setenv(), putenv() and unsetenv() will unset all previous values and
call __setenv() on all entries in the new environ array which in turn
adds them to the end of the envVars array. Calling __setenv() instead
of setenv() is done to avoid the temporary replacement of the '=' in a
string with a NUL byte. Some strings may be read-only data.

Added more regression checks for clearing the environment array.

Replaced gettimeofday() with getrusage() in timing regression check for
better accuracy.

Fixed an off-by-one bug in __remove_putenv() in the use of memmove(). This
went unnoticed due to the allocation of double the number of environ
entries when building envVars.

Fixed a few spelling mistakes in the comments.

Reviewed by: ache
Approved by: wes
Approved by: re (kensmith)

show more ...


# 2966d28c 04-Jul-2007 Sean Farley <scf@FreeBSD.org>

Significantly reduce the memory leak as noted in BUGS section for
setenv(3) by tracking the size of the memory allocated instead of using
strlen() on the current value.

Convert all calls to POSIX fr

Significantly reduce the memory leak as noted in BUGS section for
setenv(3) by tracking the size of the memory allocated instead of using
strlen() on the current value.

Convert all calls to POSIX from historic BSD API:
- unsetenv returns an int.
- putenv takes a char * instead of const char *.
- putenv no longer makes a copy of the input string.
- errno is set appropriately for POSIX. Exceptions involve bad environ
variable and internal initialization code. These both set errno to
EFAULT.

Several patches to base utilities to handle the POSIX changes from
Andrey Chernov's previous commit. A few I re-wrote to use setenv()
instead of putenv().

New regression module for tools/regression/environ to test these
functions. It also can be used to test the performance.

Bump __FreeBSD_version to 700050 due to API change.

PR: kern/99826
Approved by: wes
Approved by: re (kensmith)

show more ...


# ba174a5e 01-May-2007 Andrey A. Chernov <ache@FreeBSD.org>

Back out all POSIXified *env() changes.

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 r

Back out all POSIXified *env() changes.

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.

show more ...


# 15fdb055 30-Apr-2007 Andrey A. Chernov <ache@FreeBSD.org>

Make putenv() fully conforms to Open Group specs Issue 6
(also IEEE Std 1003.1-2001)

The specs explicitly says that altering passed string
should change the environment, i.e. putenv() directly puts

Make putenv() fully conforms to Open Group specs Issue 6
(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.

show more ...


# bdda8934 30-Apr-2007 Andrey A. Chernov <ache@FreeBSD.org>

Make setenv, putenv, getenv and unsetenv conforming to Open Group specs
Issue 6 (also IEEE Std 1003.1-2001) in following areas:
args, return, errors.

Putenv still needs rewriting because specs expli

Make setenv, putenv, getenv and unsetenv conforming to Open Group specs
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).

show more ...


Revision tags: release/6.2.0_cvs, release/6.2.0
# c879ae35 09-Jan-2007 Warner Losh <imp@FreeBSD.org>

Per Regents of the University of Calfornia letter, remove advertising
clause.

# If I've done so improperly on a file, please let me know.


Revision tags: release/5.5.0_cvs, release/5.5.0, release/6.1.0_cvs, release/6.1.0, release/6.0.0_cvs, release/6.0.0, release/5.4.0_cvs, release/5.4.0, release/4.11.0_cvs, release/4.11.0, release/5.3.0_cvs, release/5.3.0, release/4.10.0_cvs, release/4.10.0, release/5.2.1_cvs, release/5.2.1, release/5.2.0_cvs, release/5.2.0, release/4.9.0_cvs, release/4.9.0, release/5.1.0_cvs, release/5.1.0, release/4.8.0_cvs, release/4.8.0, release/5.0.0_cvs, release/5.0.0, release/4.7.0_cvs, release/4.6.2_cvs, release/4.6.2, release/4.6.1, release/4.6.0_cvs
# c05ac53b 21-Mar-2002 David E. O'Brien <obrien@FreeBSD.org>

Remove __P() usage.


# 8fb3f3f6 21-Mar-2002 David E. O'Brien <obrien@FreeBSD.org>

Remove 'register' keyword.


Revision tags: release/4.5.0_cvs, release/4.4.0_cvs, release/4.3.0_cvs, release/4.3.0, release/4.2.0, release/4.1.1_cvs, release/4.1.0, release/3.5.0_cvs, release/4.0.0_cvs, release/3.4.0_cvs, release/3.3.0_cvs, release/3.2.0, release/3.1.0, release/3.0.0, release/2.2.8, release/2.2.7, release/2.2.6, release/2.2.5_cvs, release/2.2.2_cvs, release/2.2.1_cvs, release/2.2.0, release/2.1.7_cvs, release/2.1.6_cvs, release/2.1.6.1, release/2.1.5_cvs, release/2.1.0_cvs
# 283e0c0e 17-Oct-1995 David Greenman <dg@FreeBSD.org>

Doubled the performance of getenv()/__findenv() by rewriting it to not
use strncmp()..


Revision tags: release/2.0.5_cvs, release/2.0, release/1.1.5.1_cvs
# 58f0484f 27-May-1994 Rodney W. Grimes <rgrimes@FreeBSD.org>

BSD 4.4 Lite Lib Sources


# 9199c09a 06-Jan-2010 Warner Losh <imp@FreeBSD.org>

Merge from head at r201628.

# This hasn't been tested, and there are at least three bad commits
# that need to be backed out before the branch will be stable again.


# f959b43f 07-Dec-2009 Sean Farley <scf@FreeBSD.org>

Revert behavior change to setenv(), unsetenv() and putenv() until a more
thorough security review has been completed.


# ca7520fe 07-Dec-2009 Sean Farley <scf@FreeBSD.org>

Change the behavior of setenv(), putenv() and unsetenv() to continue parsing
instead of returning an error if a corrupt (not a "name=value" string) entry
in the environ array is detected when (re)-bu

Change the behavior of setenv(), putenv() and unsetenv() to continue parsing
instead of returning an error if a corrupt (not a "name=value" string) entry
in the environ array is detected when (re)-building the internal
environment. This should prevent applications or libraries from
experiencing issues arising from the expectation that these calls will
complete even with corrupt entries. The behavior is now as it was prior to
7.0.

Reviewed by: jilles
MFC after: 1 week

show more ...


123