Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!imagen!atari!kbad From: kbad@atari.UUCP (Ken Badertscher) Newsgroups: comp.sys.atari.st Subject: Re: Extended argument passing conventions in Pexec() [MWC] Summary: ARGV can not be adopted as-is. Keywords: MWC Pexec Argument Passing Message-ID: <1453@atari.UUCP> Date: 13 Apr 89 22:26:53 GMT References: <841@per2.UUCP> Reply-To: kbad@atari.UUCP (Ken Badertscher) Organization: Atari Corp., Sunnyvale, CA Lines: 122 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 Atari R&D | No pith, just a path: Software Engine | {portal,ames,imagen}!atari!kbad