Lorenzo, It __would__ make sense if this behaviour was consistent with the 'non multiple option' behaviour. Let me show you :
option "unique" - "set a 'unique' option" string typestr="STR" optional argoptional default="unique_default" option "multiple" - "set a 'multiple' option" string typestr="STR" optional argoptional default="multiple_default" multiple Using a small test program (code below), I see : $ ./ggotest unique: unique_arg=unique_default unique_orig=(null) unique_given=0 multiple: multiple_given=0 multiple_arg[0]=multiple_default multiple_orig[0]=(null) >> excepted $ ./ggotest --unique --multiple unique: *unique_arg=unique_default* unique_orig=(null) unique_given=1 multiple: multiple_given=0 *multiple_arg[0]=(null)* multiple_orig[0]=(null) >> oops ! I expected to see the same argument for both options. According to you, maybe it is the --unique option which should have a (null) argument. Either way, the current behaviour seems inconsistent, and unaligned with the documentation : *"If it is known that a multiple option has a default value, then it can be safely assumed that the first element of generated array <option>_arg| is always set."* What do you think ? -- Fred On 19 October 2012 12:54, Lorenzo Bettini <[email protected]> wrote: > Hi > > since you also specify that 'argoptional' then the default value is not > set if you specify no argument to --foo, since the argument is optional, > so that option --foo is meant to be able to deal also with no argument > at all... that's how I interpreted the semantics when I implemented it. > > Does it make sense? > > hope to hear from you soon > cheers > Lorenzo > > P.S. please take a look at the current open (and closed) bugs to make > sure that this issue has already been raised. > > On 10/19/2012 10:57 AM, Frédéric Heitzmann wrote: > > Hi all, > > > > I defined and option like this : > > > > option "foo" - "bla bla bla" string typestr="STR" default="default_foo" > > argoptional multiple optional > > > > If I call with --foo, the default value is not added to foo_args[0]. > > Actually, foo_args[0] is a NULL pointer, while I expected that > > foo_args[0] would be string "default_foo". > > > > If I remove 'default', and set --foo without any argument, this time > > foo_args[0] is set to "default_foo". > > > > The documentation says : > > "If it is known that a multiple option has a default value, then it can > > be safely assumed that the first element of generated array > > |<option>_arg| is always set. " > > > > so it really looks like a bug to me. > > > > Can someone confirm ? > > I may work on a patch if it helps. > > > -- > Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino > ICQ# lbetto, 16080134 (GNU/Linux User # 158233) > HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com > http://www.myspace.com/supertrouperabba > BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com > http://www.gnu.org/software/src-highlite > http://www.gnu.org/software/gengetopt > http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net > > _______________________________________________ > Help-gengetopt mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/help-gengetopt >
_______________________________________________ Help-gengetopt mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-gengetopt
