🚀 go-pugleaf

In article <841@per2.UUCP> mwc.uucp!rec writes:
| My name is Roger Critchlow.  I work for Mark Williams.  I invented
| the MWC ARGV argument passing convention in October 1985.  I don't
| think either of the proposed replacements is an improvement.
| -----------------------------------------------------------------------
| Our convention is incomplete because you can't tell if the ARGV was
| actually passed by your parent or simply passed on by some intervening
| shell?
| 
[ environment comparison code omitted ]
| 
| This example is only the simplest of many procedural validations
| of the ARGV convention.  You can chase the parent pointers all the
| way to the desktop and determine who exactly is responsible for
| each part of the environment in each of the processes active.

It is simple, yes, and it simply won't work.  Using ARGV, a parent
is required to copy its environment before it execs a child.  What if
someone decides they'd like to sort the environment variables for the
child as they create the child's environment?  What if they want to
filter it?  The environment comparison fails, and validation goes out
the window.  The MWC tools already* provide a flag ("unreasonable"
command line length byte) which can be used to validate the ARGV, and it
is unused by the MWC startup code!

| I don't think that every program which uses ARGV needs be burdened
| with this sort of validation, but it's clearly possible.

One of the *main* reasons that xArgs came into existence in the first
place was that ARGV lacks validation that the arguments in the ARGV
pseudo-environment-variable really do come from one's parent.  You may
not find the validation necessary, Roger, but there are many people
who use tools which were not compiled using MWC libraries.  A typical ST
developer's toolkit contains sundry tools with a varied ancestry.  The
plain fact is that ARGV does not peacefully coexist with tools that
don't use ARGV.

| -----------------------------------------------------------------------
| Our convention is messy because it involves copying arguments around
| in the environment?
| 
| But all three proposed argument conventions require copying, and all
| three pass linkage information in the environment, and the ARGV convention
| is the most efficient of the three.
| 
[ enumeration of implementation requirements omitted ]
| 
| The ARGS and xArgs proponents are proposing to load more code into the
| runtime startup to support their proposals.  [...]
| How many independent count-allocate-copies does it
| take to start a Gemdos process?
 
Who cares???  How long does it take an 8Mhz 68000 to copy 1k, or even
(gasp) 2k of memory, even with extra processing to parse it?  Somewhere
on the order of tens of milliseconds per program invocation, if that much.
God forbid that we should fritter away people's valuable milliseconds in
our wanton disregard of startup module code efficiency.

| -----------------------------------------------------------------------
| Programs which ignore the ARGV convention for arguments end up
| mis-interpreting ARGV specified arguments as environmental variables
| and passing screwed up environments on to their children.
| 
| This problem is addressed differently by the ARGS and xArgs proposals.
| 
[ means of addressing the problem omitted ]
| 
| In article <156@np1.hep.nl> Geert J v Oldenborgh suggested truncating
| the environment after extracting the ARGV from it.  I think this is
| an excellent suggestion:  it adds one instruction, 2 words, to the
| runtime startup module and immediately cures one whole class of bugs,
| the class created by MWC compiled programs doing naive Pexec()'s.

Hah, I caught you!  You admit that ARGV is imperfect! ;-)  You are even
willing to change the startup code to make it more perfect!

| I have two solutions for binary programs which screw up the
| environment by ignoring the ARGV standard but cannot be rebuilt
| with the improved runtime startup.  Both involve the same
| transformation suggested above.
| 
| Solution 1 - call the program indirectly through a second program [...]
| Solution 2 - rewrite the binary of the offending program to
| incorporate the environment truncation into the offending
| program's runtime startup.  [...]

That's very nice, but the other two methods of extended argument passing
don't require ANYBODY to be insulated from them.  In fact, all THREE
methods can peacefully coexist in one system, except that ARGV will
cause problems for programs which haven't been "innoculated" against it.

| -----------------------------------------------------------------------
| In summary, the ARGV convention can be validated by comparing the
| ARGV received in the environment to the ARGV received by the parent;

unless the parent has done anything to the environment...

| the ARGV convention rides for free on Pexec() while the new proposals
| both involve additional overhead;

negligible additional overhead...

| and it is trivial to fix programs
| which pollute the environment by ignoring the ARGV convention.

perhaps we disagree on the meaning of the word trivial; in any case,
the other two schemes don't cause any pollution, and thus don't require
any programs to be fixed...


| If Atari wants MWC to discard the ARGV argument convention, I hope
| they'll wait until they can find something better to replace it with.  :-)
| 
|    -- rec --

If MWC wants Atari to adopt the ARGV argument convention, I hope they'll
come up with some better defenses for it. >;-)

-- 
 Ken Badertscher                 | #include <disclaimer>
 Atari R&D                       | No pith, just a path:
 Software Engine                 |   {portal,ames,imagen}!atari!kbad