Re: override and multiple options

Andre Noll wrote:
> On 11:51, Lorenzo Bettini wrote:
>>> However, the new set of options are _appended_ to the old values
>>> instead. Is this behaviour intended? If it is, is that feature
>>> documented anywhere? If it isn't intended, what could be done to fix
>>> the situation while retaining backwards compatibility?
>>>
>> Hi Andre
>>
>> I think that this is the intended behavior for multiple options, since 
>> multiple options are thought exactly to append other options to the ones 
>> already given, thus they should not be overridden;
> 
> Even if the override flag is set?

Well, the main idea is that by default an option can be specified only 
once; 'override' makes the parser not consider another occurrence of the 
same option as an error, and replace the previous value.

By definition a multiple option instead is something that can be given 
many times, thus 'override' makes no sense for it.

> 
>> it is up to the application itself to decide what to do then.
> 
> Thanks for the clarification. So if one wants to completely get rid
> of any previously given values for a certain option, one has to do
> something like
> 
> 	for (i = 0; i < conf.xxx_given; i++) {
> 		free(conf.xxx_arg[i]);
> 		conf.xxx_arg[i] = NULL;
> 	}
> 	conf.xxx_given = 0;
> 
> before calling cmdline_parser_config_file() for the second time. Is
> that the preferred way to achieve this?

yes, I think so (and I should put it in the documentation :-)

> 
>> For instance, the -O option can be given many times to the gcc compiler,
>> and it will decide that only the last one is the one to apply (at least 
>> I think it is like that, in fact, in another program, I was struggling 
>> with a prebuilt command line option to the compiler that couldn't be 
>> changed and this contained -O2 which makes it hard to debug programs: I 
>> then appended -O0 and this solved the problem).
> 
> But -O shouldn't be a multiple option at all because it usually does not
> make sense to specify -O more than once, no?

well, in gcc it does, apparently; and again, it can be interpreted as above.

It is up to the application itself to give the right semantics.

the parser generated by gengetopt only must check that an option is not 
specified more than once, but when 'override' is specified, or it is a 
multiple option

> 
> Anyway, what about programs that may read its config file more than
> once at startup? Consider for example a daemon that rereads its config
> file whenever it receives SIGHUP. Does it really make sense that the
> override feature appends to the array, making it larger and larger
> even in case the options that were declared as multiple (in the ggo
> file) haven't changed in the config file?
> 

I think that in that case it should use a brand new structure re-initialized

> This being said, I have no problems with the current behaviour as the
> workaround in the code above works fine. But it should definitly be
> documented.

yes, and probably I should write in the documentation what I wrote 
above, and provide your example.

Please, also understand that gengetopt cannot make all the checks: the 
right semantics must be implemented by the application itself.

While clearing the multiple option structure is just a matter of doing 
what you propose, or use a brand new structure, implementing 'override' 
for multiple options would make the application harder to accomulate 
multiple options the other way round.

At least, that was my humble interpretation of multiple options (also 
considering existing programs) ;-)

cheers
	Lorenzo

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