src/lib/libc/stdlib/getenv.c, branch releng/13.1

libc: further adoption of SPDX licensing ID tags.

2017-11-25T17:12:48+00:00

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using mis-identified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

Minor libc cleanup: let calloc(3) do the multiplication.

2017-03-13T04:14:03+00:00

MFC after:	3 days

libc: provide some bounds-checking through reallocarray(3).

2017-03-12T16:03:34+00:00

reallocarray(3) is a non portable extension that originated in OpenBSD.
Given that it is already in FreeBSD's libc it is useful for the cases
where reallocation involves a multiplication.

MFC after:		2 weeks
Differential Revision:	https://reviews.freebsd.org/D9955

[fix to r253380] __setenv: be explicit about placing '=' after name

2013-07-17T08:45:27+00:00

This should a regression introduced in r253380 if malloc'ed memory
happens to have '=' at the right place.

Reported by:	ache
Pointyhat to:	me (avg)
MFC after:	1 day
X-MFC with:	r253380

libc: name passed into __setenv is not necessarily NUL-terminated

2013-07-16T07:26:46+00:00

That's particularly true when __setenv is called from __merge_environ.

MFC after:	4 days

Optimize prev. commit for speed.

2012-10-03T04:46:58+00:00

1) Don't iterate the loop from the environment array beginning each time,
iterate it under the last place we deactivate instead.
2) Call __rebuild_environ() not on each iteration but once, only at the end
of whole loop (of course, only in case if something is changed).

MFC after:      1 week

Using putenv() and later direct pointer contents modification it is possibe

2012-10-02T17:44:08+00:00

to craft environment variables with similar names like that:
a=1
a=2
...
unsetenv("a") should remove them all to make later getenv("a") impossible.
Fix it to do so (this is GNU autoconf test #3 failure too).

PR:             172273
MFC after:      1 week

Revert behavior change to setenv(), unsetenv() and putenv() until a more

2009-12-07T00:22:10+00:00

thorough security review has been completed.

Change the behavior of setenv(), putenv() and unsetenv() to continue parsing

2009-12-06T23:27:24+00:00

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

Improve the comment within getenv() explaining the search order it takes to

2009-12-06T23:05:17+00:00

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