[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [help-gengetopt] make cmd_line_list and cmd_line_list_tmp static?

From: Lorenzo Bettini
Subject: Re: [help-gengetopt] make cmd_line_list and cmd_line_list_tmp static?
Date: Sun, 09 Apr 2006 21:40:44 +0200
User-agent: Mail/News 1.5 (X11/20060228)

Andre Noll wrote:
On 17:14, Gyozo, PAPP (VBuster) wrote:
" So I replaced "optind = 1" by "optind = 0" in the generated code which
" As this solved all of my problems and I can not see any drawbacks of
" this approach either, I'd suggest to let gengetopt generate "optind =
" 0" instead of "optind = 1".

Let's see what the specs says [IEEE Std 1003.1, 2004 Edition]

"The variable optind is the index of the next element of the argv[]
vector to be processed. It shall be initialized to 1 by the system,

I think the word "system" in this sentence refers to the underlying
library that _implements_ getopt (e.g. glibc), rather than to the
application that _uses_ it.  Indeed, glibc's posix/getopt.c sets this
variable to one:

        /* Index in ARGV of the next element to be scanned.
           This is used for communication to and from the caller
           and for communication between successive calls to `getopt'.

           On entry to `getopt', zero means this is the first call; initialize.

           When `getopt' returns -1, this is the index of the first of the
           non-option elements that the caller should itself scan.

           Otherwise, `optind' communicates from one call to the next
           how much of ARGV has been scanned so far.  */

        /* 1003.2 says this must be 1 before any call.  */
        int optind = 1;

The real reason I'm complaining about this change is that I have to
use a proprietary implementation of getopt_* family and this change
causes that argv[0] is always parsed as a parameter and put into the
inputs[] array.

I just tested it with 2.17-rc under glibc/Linux: Here inputs[0]
is the first option, i.e. argv[0] does not show up in inputs[].

What to do in this situation?

I don't know. Lorenzo?

Hi Andre and Gyozo

sorry for the delay

actually I haven't found your explanation (Andre) in the info file of glibc, but something that corresponds to what gyozo said:

-- Variable: int optind
     This variable is set by `getopt' to the index of the next element
     of the ARGV array to be processed.  Once `getopt' has found all of
     the option arguments, you can use this variable to determine where
     the remaining non-option arguments begin.  The initial value of
     this variable is `1'.

indeed the files you sent me work even with optind = 1.

I guess the problems you used to have were due to the fact that getopt expects the first argument in the argv array to be the name of the program (and so it discards it). So you always have to put a first element in the vector.

I think the right behavior is to go back to optind = 1

Of course I'll document this fact (and also add an example of using more parsers following the example you sent me).

I'd really like to know if the problems you had were due to this (I'm pretty sure this is the reason); as I said the files you sent me work with optind = 1 (because they pass a correct array).

Notice that, if you use the configuration parser generated by gengetopt, this will construct a correct array (by inserting, as the first element, the name of the program).

I hope to hear from you soon!

thanks for the feedback!

|  Lorenzo Bettini          ICQ# lbetto, 16080134     |
|  PhD in Computer Science                            |
|  Dip. Sistemi e Informatica, Univ. di Firenze       |
|  Florence - Italy        (GNU/Linux User # 158233)  |
|  Home Page        :    |
|         XKlaim language  |
| Deep Purple Cover Band |
|           |
|              |
|       |
|    |

reply via email to

[Prev in Thread] Current Thread [Next in Thread]