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 31 00:33

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)
Re: [vox-tech] writing free getopt, ran into a dilemma...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Thu, Mar 28, 2002 at 10:12:29AM -0800, Micah Cowan wrote:
> On Thu, 2002-03-28 at 00:35, Mark K. Kim wrote:
> > 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.
> Well, POSIX says that options should always be supplied before
> arguments, so that's why POSIX-conforming implementations don't need to
> permute the order in argv.  Intermixing options with arguments is a GNU
> extension,

  First off Micah is absolutely correct about POSIX and options.  Strict
POSIX stuff only accepts command options as the first bunch of options to 
a command the first non-option found stops parsing of options.  

  This is why if you type 'ls foo* -ltr' on a Solaris version of ls
you will get a standard ls format and then an error about 
'-ltr: file not found' but if you type the same thing on a Linux
system you get a long listing sorted reversely by time (youngest files

> 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).


  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);

POSIX adds the following one additional main:
  int main(int argc, const char **argv, const char **envp);

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

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

  /* externs are optional, and "*argv[]" is interchangeable with "**argv" */

- If you think the declaration of main or getopt don't match any of the
  above could you give your version and some online reference for that

  If the declaration of main above is correct there is nothing to 
prevent someone reordering the elements in the main function's argv... 
which is what is passed into getopt by _almost_ every caller.
  It would seem the GNU people could just remove the const from their 
header so if POSIX actually _requires_ the const then people would be 
able to rightly complain it doesn't "obey" the POSIX standard out of 
the box... but the GNU version gives users at least two ways to get
POSIX compatible getopt at run time (POSIXLY_CORRECT and '+' prefix),
and in theory (not current practice) the coder could request POSIX 
compatibilty at compile time via '#define POSIX_SOURCE'.

  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'.
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:
O'Reilly and Associates
For numerous book donations.