Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcvax!np1!t68
From: t68@np1.hep.nl (Jos Vermaseren)
Newsgroups: comp.sys.atari.st
Subject: Re: Extended argument passing conventions in Pexec() [MWC]
Keywords: MWC Pexec Argument Passing
Message-ID: <163@np1.hep.nl>
Date: 18 Apr 89 14:09:48 GMT
References: <841@per2.UUCP> <1453@atari.UUCP> <546@bdt.UUCP>
Organization: Nikhef-H, Amsterdam (the Netherlands).
Lines: 50

In article <546@bdt.UUCP>, david@bdt.UUCP (David Beckemeyer) writes:
> In article <1453@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes:
> 
> [ about the MWC ARGV method ]
> 
> >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!
> >
> 
> Ken, it sure looks like you want to attack MWC here.  If the method is
> "standard", "good" programs won't mess with the environment in "bad" ways.
> 
> I think something that Allan Pratt (sp?) suggestted a long time ago where
> the parent places a variable like "PARENT=" or simething which contains the
> parents basepage address is a reasonable additional method of validation
> of the ARGV environment.  Also the MWC startup could be modified to use
> the "unreasonable" command line length byte and Roger's suggestion of 
> nulling out the env. at the ARGV is also good.

I think Ken misses something more: The parent doesn't have to copy
anything. When Pexec starts a program the loader copies the environment
string, so the user may hack it up as much as he wants it without
affecting the environment of the parent.

The MWC method (including writing a \0 over the ARGV if you want to
incapacitate an ARGV) works well already for ages by giving validation
via PBP=parentbasepageaddress in front of ARGV. You may also have the
startup code write the \0 over the PBP which is better.

The major shells use something like it (or part of it), MWC uses it,
Aztec uses it (they use Gulam). Only Turbo C didn't use any but the
startup code is fixed quickly. Laser C is the one that opted to either
not understand the convention or go deliberately their own way. So what,
it isn't a good compiler anyway (the code is 30% slower than turbo and
the best debugger is the one of MW). 

First Atari doesn't give us decent documentation, and then when a
standard is emerging they are going to criticize it and talk about
fantastic schemes that 1: aren't better and b: NOBODY is using.
Keep it up guys!

Jos Vermaseren

Claimor: This opinion is mine and my mood ain't too good.