bug in putenv()!

[John Mashey]

The "environment", once upon a time was, in sequence:
	a) A small number of fixed-length strings kept in the u-area,
	in PWB/UNIX, set upon login, and essentially read-only thereafter.
	b) A magic file opened by a shell, which left a high-numbered file
	descriptor open so that descendent shells could look at it,
	assuming no intervening processes had closed it. [intermediate
	versions of the Bourne shell, before 7th edition].
	c) A variable list of name-value pairs, kept in kernel data space,
	and managed by system calls, by the "family" of processes that owned it.
	(Proposed way of doing it for V7, never implemented, because:
		1) Mismatch of the semantics of this, and what people really
		wanted to do with the environment.  In particular, what did
		a parent process see, and when, if a child process modified
		the environment? For various reasons, we believed that it was
		Evil to introduce something whose semantics let it be
		an inter-process communication method, when there were much
		better alternatives with firmer bases available.
		2) A fair amount of machinery, complexity, and code for the
		intended purpose,which was mostly to permit clean-semanticed
		inheritance of "invisible" parameters, i.e., data structures
		that could be passed around without bothering the masses of
		code out there.
	d) The current model, suggested by DMR, which treats the environment
	almost identically to the argument list, i.e.:
		a) It is allocated on the stack at exec time; it is NOT
		malloced.  Only a small amount of kernel code knows anything
		about the environment, and once it copies it to the being-
		built image, it forgets about it.  Remember that this was
		designed in the days when the most commonly-used machines
		allowed all of 64Kbytes of kernel code, not in the latter days
		of creeping featurism :-)
		b) Many programs don't need to look at the environment much;
		many need to look at it; a few need to change it.  Thus,
		the design was tuned in that direction.
		c) The semantics are simple: you start with the environment
		passed in to you as a behind-the-back environment list.
		If you don't do anything, you children inherit it.
		If you change it, your ancestors know nothing about it,
		but your children still inherit it.
		If you put a lot of junk in the environment, YOU pay for
		it in YOUR process address space consumption.
		----
		d) Personally, I thought this was a classically-elegant way
		of solving the bulk of the problem with really-minimal
		mechanism, except for those few programs that did a lot of
		environment modification; typically, those programs (like *sh),
		have their own large set of dynamic storage allocation code
		anyway, and are not going to use any general-purpose mechanism.

Anyway, if you understand the form and nature of (argv) and just think
of the environment as another of those, it's probably easier to understand.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash at mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086