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

[Micah Cowan]

> > Intermixing options with arguments is a GNU
> > extension, and GNU pulls some mildly dirty tricks to get it (such as
> > permuting argv, despite the fact that it's elements are declared const).
> 
> Micah,
> 
>   I am slightly confused, "it's elements are declared const", I've been
> having a very hard time finding some site which will state something like
> POSIX/ANSI C/ISO C require the following prototypes...
> 
> 
> Here is what I believe the valid declarations to be (these from ANSI C):
>   int main(void);  
>   int main(int argc, const char **argv);

No, the second shouldn't have the "const".
> 
> POSIX adds the following one additional main:
>   int main(int argc, const char **argv, const char **envp);

This is a standard UNIX convention, but is not POSIX (at least, I can't
find it).

> 
> POSIX declares:
>   int getopt(int argc, char * const *argv, const char *optstring);

More or less.

> 
> However the GNU documentation declares:
>   int getopt(int argc, char **argv, const char *optstring);

Mine sure doesn't.  Mine says "char * const *argv".  So does the
header.  I have never seen a Linux system with a different declaration
than this, so now you have my curiosity piqued, as to what system you're
running.  The manpage is dated 8 May 1998, ships with RH 7.1; my glibc
is currently 2.2.4.  BTW, the manpage gives a reason as to why this is
the case, I just think it's a very ugly way of doing it.

>   The one valid bug I see is that GNU getopt.h and getopt.c both use 
> 'char * const *argv' and that conflicts with the documentation 
> of 'char **argv'.

But not with my documentation, obviously. So it looks like they
originally had it your way but later changed it for compatibility with
certain other systems (although why such compatibility is necessary with
*BSD escapes me - compatibility with POSIX would be a good reason;
libiberty might be another).

Anyway, that's what I was talking about.

Cheers,
Micah