jbc@mcc-db.UUCP (John B. Chambers) (07/15/85)
From: John Chambers (guest moderator) <ut-sally!std-unix> Topic: getopt (command line arguments) continued ---------------------------------------------------------------------- Date: Thu, 11 Jul 85 14:07:41 EDT From: Keith Bostic <keith@seismo.CSS.GOV> Subject: getopt(3) (again...) Just when I thought it was safe to read my mail... > i made a couple of changes. esthetics, absolutely no stdio if > desired, and the opterr variable. here's my revision: I'm getting pretty tired of this whole issue -- in fact, I kept starting to reply to your mail and then deciding not to, figuring that if I didn't maybe the whole thing would die off. *sigh* Well, my friend, here's a reply. The content is simple. You are wrong. Pure-d, absolutely, wrong. Point by point: esthetics: Esthetics are all very well and good, and we could argue for the next several days as to whether a goto can be considered esthetical, or whether indentation should be 4 characters or 8, or whether "void" is really a good idea, or if "index()" *really* needs to be declared outside of the local routine, etc. etc. until the cows return from pasture. On the other hand, 4.3BSD is going to use my code. Since it works, I see no value in making the wheel ever so slightly rounder, if, in fact, you managed to do so. I do not wish to spend the rest of my life figuring out that some getopt really does work. I would like to assume that the one that comes with 4.3 does work and I can therefore turn my attention to other parts of an ailing program, after doing a very brief "diff" of the two modules. The world does not need another getopt. When I re-wrote the one I did, it did. absolutely no stdio if desired: Well, for an error condition that's going to happen once before the program exits, it's gonna be faster. You saved about 2 routine calls, near as I can figure. You didn't save any library space, which is why I changed the original fprintf() calls to fputs() calls. the opterr variable: The other two items, I could live with. Here, on the other hand, you have single-handedly created a real pain in the ass in terms of portability. Scenario #1: Bell Labs doesn't ever decide to use opterr. Fine and dandy, except that people who use your new flag will find that their code will not run as expected on USG UNIX. Scenario #2: USG uses the flag, but makes it backward compatible. Well, little problem here, BSD code will now not run on USG machines which is the situation we had before we wrote the damn thing. Scenario #3: USG uses the flag, but doesn't make it backward compatible. Unlikely, but possible. Well, we change getopt(3) to be like Bell, breaking all of the code that has been written to use your new flag, or, of course, we could just diverge the two systems again. Fun, fun! As it is (or was, before this new edition) we just change to use USG's new opterr behaviors and go on as before, unless they don't make it backward compatible, in which case the entire UNIX world is in the same boat. I would have been much more amenable to changes two months ago; if you can get Mike Karels to use your version rather than mine, I will again be much more amenable to changes. Well, with the exception of your use of opterr. --keith ---------------------------------------------------------------------- -- John B. Chambers, Microelectronics and Computer Technology Corp., Austin, TX {ihnp4,seismo,ctvax}!ut-sally!mcc-db!jbc, jbc@ut-sally.ARPA, chambers@mcc.ARPA