🚀 go-pugleaf

In article <156@np1.hep.nl> t19@np1.hep.nl (Geert J v Oldenborgh) writes:
> I wonder why we could not use the present 'standard' with one small diff:
> let the sartup code of a program kill the extra part of the environment by
> putting a 0L on "_P(B=...)".  This unclutters the environment and avoids
> misunderstandings of its children, the main arguments against this scheme.

The only thing that fixes is a "smart" program finding surprising things
in its environment.  (That is, an argument FOO=3 will also look like an
environment variable FOO with value 3). 

This doesn't help dumb programs at all.  A dumb program will still get
this funny thing in its environment, and will still pass that along to
its children.  Worse, if the dumb program actually tries to change its
environment, it might put a new (and important) variable at the end,
after the ARGV and the rest, and a "smart" program will lose this when
it nulls out ARGV. 

So ARGV is bad for dumb programs.  We need something which does not
violate the format of an environment variable (i.e.  no embedded nulls
allowed) and therefore doesn't confuse either dumb programs which change
their environments or smart ones which use getenv(). 

We also need to address validation: finding ARGV in your environment
does not mean that the args were meant for you.  MWC kindly puts a
strange number in the command-line length byte ($7f), but, alas, doesn't
check it.  If it did check this would solve the problem, because a dumb
program might blindly pass along the ARGV in the environment, but it's
not likely to put the same number in the command-line length byte. 

Another validation technique is to use the process' PID (basepage
address) to identify who put the args in the environment: eight bytes
can encode the PID of the culprit, and this number could be checked
against the "parent's basepage" field in the child's basepage; a match
means these args really came from your parent.  This removes the problem
of putting a funny number in the command-line length byte, which might
just happen accidentally. 

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt