home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / atari / st / tech / 4209 < prev    next >
Encoding:
Text File  |  1992-07-31  |  3.7 KB  |  103 lines

  1. Newsgroups: comp.sys.atari.st.tech
  2. Path: sparky!uunet!cs.utexas.edu!torn!watserv2.uwaterloo.ca!watserv1!mks.com!ant
  3. From: ant@mks.com (Anthony Howe)
  4. Subject: Re: Problems with ARGV
  5. Message-ID: <1992Jul31.143122.7547@mks.com>
  6. Sender: ant@mks.com (Anthony Howe)
  7. Organization: Mortice Kern Systems, Waterloo, Ontario, CANADA
  8. Date: Fri, 31 Jul 1992 14:31:22 GMT
  9. Lines: 92
  10.  
  11. dltest@castle.ed.ac.uk (Kevin Davidson) writes:
  12. >ant@mks.com (Anthony Howe), babbling inanely in article <1992Jul29.130755.27902@mks.com>, claimed:
  13.  
  14.                  ^^^^^^^^^^^^^^^^
  15.                  Uncalled for and impolite.
  16. If you don't agree then say so, but there is no need to be uncivil about it.
  17.  
  18.  
  19. >>Julian F. Reschke writes:
  20. >>>In article <9130026@hpbbrd.bbn.hp.com>, jensk@hpbbrd.bbn.hp.com (Jens Kilian)
  21. >>>says:
  22. >>>>    [Problem with NULL parameters to programs
  23.  
  24. >>>>    [suggested fix was using another env.var. to record empty
  25. >>>>    [string positions.
  26.  
  27. > So where does this environment variable go ? Before ARGV ? Then programs
  28. >that don't understand will pass it onto their children, so we need *another*
  29. >flag to say the information is valid. Yeeuch!
  30.  
  31. I'd forgotten about that.
  32.  
  33. >After ARGV ? How do we tell we are after ARGV, if the double null is possibly
  34. >just a null parameter ? The information we need is somewhere else...
  35. >(Think about this:
  36. >
  37. >prog.ttp arg1 "" ARGV_EMPTY=foo bar bletch
  38. >
  39. >(yeah it's unlikely, but *possible*)
  40. >
  41. >It looks like there should have been a length flag somewhere or maybe
  42. >some other terminator than \0\0.
  43. >The other solutions I've seen have problems too:
  44. >1) escape characters (\001 etc) will really confuse older programs.
  45. >2) adding spaces doesn't seem too bad, but there has to be a tidier fix
  46. >   than this.
  47. >
  48. >I'd say put a length flag or the value of argc somewhere. I'd suggest
  49. >breaking MWC programs and putting "ARGV=argc\0arg1\0arg2\0\0arg4\0\0"
  50.  
  51. This sounds pretty good too.  Having never used MWC, could someone
  52. explain what MWC startup code uses the first ARGV parameter for?. 
  53.  
  54. Idea 1
  55. ------
  56. Since most C startup just scan the environment for string "ARGV", why
  57. not encode argc in the ARGV name:
  58.  
  59.     ARGV6=<MWC stuff>\0arg1\0\0arg3\0\0argv5\0\0
  60.  
  61.         ^^ Place argc here in the name.  It is then left to the
  62. C startup to correctly parse the env. for /ARGV[0-9]+=/.  This is by no
  63. means perfect solution for old programs, especially if their C startup
  64. looks for the string "ARGV=" instead.
  65.  
  66. Idea 2
  67. ------
  68. An alternative would be to place the encoded string of empty positions 
  69. _after_ the double NULL.
  70.  
  71.     ARGV=\0arg1\0arg3\0arg4\0\0EMPTY=2,5\0\0
  72.  
  73. would represent
  74.  
  75.     argc = 6;
  76.     argv[] = { "", "arg1", "", "arg3", "argv4", "", NULL };
  77.  
  78. The ARGV could be left and parsed as it always has by older programs.
  79. Newer ones could check immediately following the double NULL for the
  80. EMPTY string list.
  81.  
  82.  
  83. >if MiNT can pass open file descriptors to processes' children. I think
  84. >something somewhere will be broken by whatever method we choose, and
  85. >this one at least is aesthetically more pleasing.
  86. >
  87. > As an aside, who else is still using Sozobon 1.2 ? Can anyone tell me
  88. >why I should move to Sozobon 2.0 or 1.33i ? What's the difference anyway ?
  89. >...
  90.  
  91. The only reason I still use 1.2 is because I have the source.  The other
  92. versions seemed too unstable at the time and without source.  I decided to
  93. wait till a stable version with source was released.  I'm still waiting.
  94. It would be nice to have longer names, handle ANSI prototypes, be able
  95. to switch between int == short and int == long, allow structures and
  96. arrays to be greater than 32K, and use long for array indexes.
  97.  
  98. -ant
  99. -- 
  100. ant@mks.com                                                   Anthony C Howe 
  101. Mortice Kern Systems Inc. 35 King St. N., Waterloo, Ontario, Canada, N2J 6W9
  102. "Nice legs.  For a human that is." - Worf (Q-pid)
  103.