getopt(3) (again...)

[John B. Chambers]

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 at 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 at ut-sally.ARPA, chambers at mcc.ARPA