[vorbis-dev] Please gix getopt

[Jeff Squyres]

On Mon, 12 Feb 2001, Michael Smith wrote:

> > Sidenote: we could avoid this whole issue by only using getopt(), and not
> > using getopt_long().
>
> They're functionally different, though. If they did the same thing,
> then it wouldn't be an issue. The GNU getopt_long() is more useful.

I was implying that we restrict ourselves to the getopt() functionality.

> Since we have to include a copy of getopt anyway (for the several
> non-unix platforms vorbis-tools (well, oggenc and probably
> vorbiscomment) support), it's best to use one that we can just take
> and use, without having to have things work differently on different
> platforms.

This is a good point, though -- my unix bais blinded me here again.

More below, though.

> > Er... but this is *exactly* what is currently done on POSIX systems that
> > don't use GNU libc (all POSIX systems have getopt()).  Linux is not the
> > only flavor involved here.
>
> No, it isn't. Other platforms DO NOT have gnu getopt. 'standard' unix
> getopt is, again, NOT THE SAME. It does different things differently.
> Having the behaviour be different depending on what unix you're using
> is not an option.

a) we don't use any of the GNU extensions of getopt()
b) all other unixes implement getopt() the same (i.e., without GNU
   extensions)
c) further, we don't use getopt() at all; only getopt_long() (I just went
   and looked; I didn't realize this before)
d) getopt() is not used to implement getopt_long()

See below.

> Well, if you want to excise getopt() completely from our local
> getopt.[ch], that'd be possible. Not sure that it's USEFUL, but it
> wouldn't break anything (unless getopt_long() uses it internally, I
> haven't looked). If not, we only want getopt_long, so we could just
> rip out the other stuff. No real need for it, though, that I can see.

Let's do this.  We don't use getopt(), so we don't need to redefine it on
systems that already have it.  It's a very short function that just turns
around and calls _getopt_internal() anyway; it's trivial to remove.

Having configure checks to see if getopt_long() is on the system is
probably not necessary because the getopt* files have appropriate #if's
for this already.

There is the name-clash issue with optind, etc., however.

You say that it's not an issue and it doesn't cause a problem.  Perhaps it
doesn't cause a problem, and perhaps I'm just being too anal.  But it
still bothers me.  This is a slipperly slope.

> > We can't have a "getopt.h", because it could clash with an OS "getopt.h"
> > (e.g., Linux).  The code will look like this:
>
> No, it can't. This is precisely WHY C has two different ways to
> include appropriate include files: #include <getopt.h> and #include
> "getopt.h" have different meanings. There's no problem.

But it doesn't work in gcc (2.95.2, at least).

Try putting garbage in the included getopt.h and compiling oggenc.  It
grabs the local getopt.h regardless of whether you use "getopt.h" or
<getopt.h> -- it never grabs /usr/include/getopt.h.

> > It finally generated discussion, too.  :-)
>
> Your previous discussion finally got me to fix the problem with
> ogg123.

...but vorbiscomment is still broken.  Hence, my further discussion to
*fix* the problem, not hack around the problem until another executable is
added that also uses getopt_long().

{+} Jeff Squyres
{+} squyres at cse.nd.edu
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.