From: dltest@castle.ed.ac.uk (Kevin Davidson)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Problems with ARGV
Summary: proposed ARGV extension a dodgy idea.
Date: 30 Jul 92 09:08:49 GMT
Followup-To: comp.sys.atari.tech
Organization: Edinburgh University

ant@mks.com (Anthony Howe), babbling inanely in article <1992Jul29.130755.27902@mks.com>, claimed:
>Julian F. Reschke writes:
>>In article <9130026@hpbbrd.bbn.hp.com>, jensk@hpbbrd.bbn.hp.com (Jens Kilian)
>>says:
>>>	[Problem with NULL parameters to programs
......
>
>>Your proposal for an ARGV extension seems to work. If 'we' all (MiNT-Libs,
>>and GNU-Libs, PureC startup code and so on) agree on this, that could be
>>a solution...
>
  I don't think it will, see below.

>Well, I've been working on an ANSI/POSIX library for Sozobon C 1.2.  I've
>provided my own C startup that supports ARGV.  If you're going to do
>this, which seems reasonable, you'll have to pick a better name than
>ARRGH for the env.var. since it has no meaning.  Something like
>
>	ARGV_EMPTY=index1, index2, ... indexN\0
>
>would be more acceptable.
>

 So where does this environment variable go ? Before ARGV ? Then programs
that don't understand will pass it onto their children, so we need *another*
flag to say the information is valid. Yeeuch!
After ARGV ? How do we tell we are after ARGV, if the double null is possibly
just a null parameter ? The information we need is somewhere else...
(Think about this:

prog.ttp arg1 "" ARGV_EMPTY=foo bar bletch

(yeah it's unlikely, but *possible*)

It looks like there should have been a length flag somewhere or maybe
some other terminator than \0\0.
The other solutions I've seen have problems too:
1) escape characters (\001 etc) will really confuse older programs.
2) adding spaces doesn't seem too bad, but there has to be a tidier fix
   than this.

I'd say put a length flag or the value of argc somewhere. I'd suggest
breaking MWC programs and putting "ARGV=argc\0arg1\0arg2\0\0arg4\0\0"
if MiNT can pass open file descriptors to processes' children. I think
something somewhere will be broken by whatever method we choose, and
this one at least is aesthetically more pleasing.

 As an aside, who else is still using Sozobon 1.2 ? Can anyone tell me
why I should move to Sozobon 2.0 or 1.33i ? What's the difference anyway ?
What does Heat'n'serve mean ? Have either of these fixed all the short==int
assumptions in the source that threw me when I built it as a Sun-based
cross compiler ? (I seem to remember somewhere a `#define short int'
somewhere !!!)
I'd like to make sure my programs will run with MiNT (when I can afford
to upgrade from 1 -crowded- meg), so is there a MiNT friendly libc ?
(the dlibs I have uses tight loops for sleep() etc.)

 Is anybody out there using MiNT on a 1040st ? How ? What shell are
you using ? Tcsh seems to be too big, and gulam doesn't understand job
control. (I don't want to know about bourne-shell lookalikes I'm a BSD
man.)

>-ant
>-- 
>ant@mks.com                                                   Anthony C Howe 
>Mortice Kern Systems Inc. 35 King St. N., Waterloo, Ontario, Canada, N2J 6W9
>"Nice legs.  For a human that is." - Worf (Q-pid)



	.Kevin.
Kevin.Davidson@ed.ac.uk | dltest@castle.ed.ac.uk | dltest@festival.ed.ac.uk
Newsgroups: comp.sys.atari.st.tech