NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/atari/st/tech/4396

Internet Message Format | 1992-08-12 | 2.6 KB

Path: sparky!uunet!pipex!unipalm!uknet!fulcrum!its!silver.its.bt.co.uk!jvt
From: [e-mail] (John Trickey)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Null arguments with ARGV
Message-ID: <[e-mail]>
Date: 12 Aug 92 16:30:35 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: @its.bt.co.uk
Organization: BT Group Computing Unix Support, Birmingham, UK
Lines: 49

I have been following this thread with more than a little bemusement at
the intricasies of passing args through TOS. Probably the way to have
avoided all of this would have stored the *argv[] array in the parent
and passed a pointer to the child, yes in the environment if you have
to!

However, we do not have a clean slate so compatibility must be
paramount. First we must consider that old applications being passed a
null arg will fail anyway. That means we only need consider new
applications as long as we leave ARGV untouched.

So now we must mandate a new variable (say ARGN --- call it what you
want) which will hold pointers to the null args.

> app arg1 "" arg3 "" arg5

wil produce
ARGN=2,4
ARGV=\bin\app\0arg1\0arg3\0arg5\0\0

All we are left with is the "validity of ARGN" problem. Well, since GEM
only copies the environment up to the first \0\0, then ARGV **must** be
the last entry in the environment for this mechanism to work. Similary
for the exec mechanism to work, ARGN will be the penultimate entry and
for it to be valid
    (getenv(ARGV) == (getenv(ARGN)+strlen(getenv(ARGN))+6))
Now this is not perfect as a non conforming application that execs could
pass on ARGN and ARGV in that configuration and so lead to chaos.
Conforming applications could remove the ARGN value after use on startup
which would limit the damage but its only really a partial cure.

Umm, coming back to the conclusion that all existing applications could
potentially break, then there is little mileage in trying to bend the
existing method to cope so why not consider a new method that will run
alongside the existing argv? If the *argv[] array was stored in the
child and pointed to the strings (or WHY) in the exec call, the address
of argv could be passed as a hex represented string in the environment
along with the current ARGV. The cost penalty is low at 4n + 4 bytes +
new env variable. This should be alright as long as a child does not
outlive its parent (MiNT etc?).

Hope I've provided some food for thought.

John
--
John Trickey <[e-mail]>
       Voice: [phone]     Fax: [phone]
(Home) <[e-mail]> || <[e-mail]> || G4REV @ GB7FLG
       [phone]