home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v1 / text0021.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  3.5 KB
  1. From: John Chambers (guest moderator) <ut-sally!std-unix>
  2.  
  3. Topic: getopt (command line arguments) continued
  4.  
  5. ----------------------------------------------------------------------
  6.  
  7. Date: Thu, 11 Jul 85 14:07:41 EDT
  8. From: Keith Bostic <keith@seismo.CSS.GOV>
  9. Subject: getopt(3) (again...)
  10.  
  11.  
  12. Just when I thought it was safe to read my mail...
  13.  
  14. > i made a couple of changes.  esthetics, absolutely no stdio if
  15. > desired, and the opterr variable.  here's my revision:
  16.  
  17. I'm getting pretty tired of this whole issue -- in fact, I kept starting
  18. to reply to your mail and then deciding not to, figuring that if I didn't
  19. maybe the whole thing would die off.  *sigh*  Well, my friend, here's
  20. a reply.  The content is simple.  You are wrong.  Pure-d, absolutely,
  21. wrong.
  22.  
  23. Point by point:
  24.  
  25. esthetics:
  26.     Esthetics are all very well and good, and we could argue for the next
  27. several days as to whether a goto can be considered esthetical, or whether
  28. indentation should be 4 characters or 8, or whether "void" is really a good
  29. idea, or if "index()" *really* needs to be declared outside of the local
  30. routine, etc. etc. until the cows return from pasture.  On the other hand,
  31. 4.3BSD is going to use my code.  Since it works, I see no value in making
  32. the wheel ever so slightly rounder, if, in fact, you managed to do so.  I do
  33. not wish to spend the rest of my life figuring out that some getopt really
  34. does work.  I would like to assume that the one that comes with 4.3 does work
  35. and I can therefore turn my attention to other parts of an ailing program,
  36. after doing a very brief "diff" of the two modules.  The world does not need
  37. another getopt.  When I re-wrote the one I did, it did.
  38.  
  39. absolutely no stdio if desired:
  40.     Well, for an error condition that's going to happen once before the
  41. program exits, it's gonna be faster.  You saved about 2 routine calls, near
  42. as I can figure.  You didn't save any library space, which is why I changed
  43. the original fprintf() calls to fputs() calls.
  44.  
  45. the opterr variable:
  46.     The other two items, I could live with.  Here, on the other hand,
  47. you have single-handedly created a real pain in the ass in terms of
  48. portability.
  49.  
  50. Scenario #1:
  51.     Bell Labs doesn't ever decide to use opterr.  Fine and dandy,
  52.     except that people who use your new flag will find that their
  53.     code will not run as expected on USG UNIX.
  54.  
  55. Scenario #2:
  56.     USG uses the flag, but makes it backward compatible.  Well, little
  57.     problem here, BSD code will now not run on USG machines which is
  58.     the situation we had before we wrote the damn thing.
  59.  
  60. Scenario #3:
  61.     USG uses the flag, but doesn't make it backward compatible.
  62.     Unlikely, but possible.  Well, we change getopt(3) to be like
  63.     Bell, breaking all of the code that has been written to use your
  64.     new flag, or, of course, we could just diverge the two systems
  65.     again.  Fun, fun!
  66.  
  67. As it is (or was, before this new edition) we just change to use USG's
  68. new opterr behaviors and go on as before, unless they don't make it
  69. backward compatible, in which case the entire UNIX world is in the same
  70. boat.
  71.  
  72. I would have been much more amenable to changes two months ago; if you
  73. can get Mike Karels to use your version rather than mine, I will again
  74. be much more amenable to changes.  Well, with the exception of your use
  75. of opterr.
  76.  
  77. --keith
  78.  
  79.  
  80. ----------------------------------------------------------------------
  81.  
  82. -- 
  83.  
  84. John B. Chambers, Microelectronics and Computer Technology Corp., Austin, TX
  85. {ihnp4,seismo,ctvax}!ut-sally!mcc-db!jbc, jbc@ut-sally.ARPA, chambers@mcc.ARPA
  86.  
  87. Volume-Number: Volume 1, Number 22
  88.  
  89.