l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2002 Mar 28 13:12

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
[vox-tech] writing free getopt, ran into a dilemma...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vox-tech] writing free getopt, ran into a dilemma...

Keywords: getopt, license issues, GPL, BSD, optind

Hey guys,

I mentioned some months ago about how I was using GPL's "getopt" library
in one of my company programs, and I was wondering about the GPL
distribution issues.[1]

Anyway, now I'm writing a software I want to release with BSD license,
but I also want the GNU getopt statically-linked.  Since I can't do that,
I decided to write my own GNU-compatible getopt library.  I know Micah
offered to do this if I wanted it badly enough, but I thought it'd be an
interesting challenge so I decided to try it myself.

The library is interestingly working really well.  I wrote a test program,
and I can't tell the difference between the GNU version and mine! :)  But
I've ran into a dilemma regarding how the library should behave, and I
thought I should get some feedback from this group of geniuses :)

The getopt library has the following parts:

   char* optarg; (the argument to an option)
   int optind;   (argv[optind] will be processed at next getopt() call)
   int opterr;   (if true, getopt() will print error on invalid option)
   int optopt;   (getopt() returns this on invalid option)

   int getopt(int argc, const char* argv[], const char* optstr);
                 (the actual getopt() call)

I implemented everything.  optarg, opterr, and optopt work exactly
identical to GNU's getopt.  However, optind is a little different because
my library doesn't reshuffle argv[] like GNU's getopt.  That's okay with
me, but things get hairy if "optstr" doesn't have '-' as its first
character -- then the programmer is expected to search the remaining
argv[] starting with "optind"... but due to GNU getopt's flexible nature,
there could be unhandled entries in argv[] not only at the end but in the
middle, too (creating "holes" of unhandled optarg in argv[]).  So where
should "optind" point to by the time "getopt"  finishes processing all the
options and there are "holes" of unhandled optarg only plain strings
remain?  (That's a little long and confusing; I hope you understand all
that :)

I think I now understand why GNU shuffles argv[].  But I don't need this
to be fully compatible with BSD's getopt; I just need it to behave in
reasonable manner.  I'd like to hear some ideas and what you think the
behavior should be and how it's better than others.



[1] - Interesting how that issue came up on Slashdot a couple days ago,
and the answers were pretty much what I got here :)

Mark K. Kim
PGP key available upon request.

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!