override and multiple options

[Andre Noll]

Hi

I just noticed a somewhat weird behaviour of gengetopt's config file
parser in combination with multiple options and the override feature.

If a (string) option is declared as multiple in the ggo file and was
given one or more times when calling the config file parser for the
first time, everything works as expected: the xxx_given field contains
the number of times this option was given, and xxx_option_arg[]
is a NULL-terminated array of that size containing the given values.

If the config file parser is later called again with a params struct
that enables override, I would expect it to _replace_ the array by
the values which have been found in the config file during this second
call. After all, this is what the word "override" indicates.

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?

Thanks
Andre
--
The only person who always got his work done by Friday was Robinson Crusoe


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Andre Noll wrote:

> Hi
>
> I just noticed a somewhat weird behaviour of gengetopt's config file
> parser in combination with multiple options and the override feature.
>
> If a (string) option is declared as multiple in the ggo file and was
> given one or more times when calling the config file parser for the
> first time, everything works as expected: the xxx_given field contains
> the number of times this option was given, and xxx_option_arg[]
> is a NULL-terminated array of that size containing the given values.
>
> If the config file parser is later called again with a params struct
> that enables override, I would expect it to _replace_ the array by
> the values which have been found in the config file during this second
> call. After all, this is what the word "override" indicates.
>
> 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; it is up to the
application itself to decide what to do then.

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

I agree with you that this should be stressed in the documentation: I
hadn't written that because I gave it for granted, but that's my mistake :-)

any other in the list have opinion about this?

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


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Andre Noll]

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?

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

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

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?

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.

Andre
--
The only person who always got his work done by Friday was Robinson Crusoe


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Tim Post-3]

Hi Lorenzo,

On Fri, 2008-12-12 at 11:51 +0100, Lorenzo Bettini wrote:

> 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).
>
> I agree with you that this should be stressed in the documentation: I
> hadn't written that because I gave it for granted, but that's my mistake :-)
>
> any other in the list have opinion about this?

There are very rare times when I've used one modifier that operates on
the current optarg each time.

For instance, a program that splits its logs, taking a -L (--level)
modifier for each:

./foo -f /var/log/foo-panic.log -L3 -f /var/log/foo-normal.log -L1, etc

However, I have not seen/done this in a really long time. But, in this
case the value of the last -L passed modifies only the behavior of the
previous -F option. The kludge needed to make this sane is ugly, I'm not
sure why someone would do it deliberately unless they had to match what
existed.

I would agree with what you wrote as being standard behavior (I think
POSIX has something to say about it too, I'll try to find the
reference).


Cheers,
--Tim



_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Andre Noll]

On 14:17, Lorenzo Bettini wrote:
> By the way, an easy work around (and also a feature enhancement) could
> be add another field to the argument structure (let me compliment with
> myself by using a structure instead of many parameters to the parser
> function, which makes it extensible without breaking existing code ;-):
>
> override_multiple with the semantics you propose!

Yes, that's exacly what I had in mind too :)

And yes again, it was wise and anticipatory to design the public
functions so that they take (pointers to) structures rather than
single values.

Andre
--
The only person who always got his work done by Friday was Robinson Crusoe


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

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


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

By the way, an easy work around (and also a feature enhancement) could
be add another field to the argument structure (let me compliment with
myself by using a structure instead of many parameters to the parser
function, which makes it extensible without breaking existing code ;-):

override_multiple with the semantics you propose!

what do you think?

cheers
        Lorenzo


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Tim Post wrote:

> Hi Lorenzo,
>
> On Fri, 2008-12-12 at 11:51 +0100, Lorenzo Bettini wrote:
>
>> 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).
>>
>> I agree with you that this should be stressed in the documentation: I
>> hadn't written that because I gave it for granted, but that's my mistake :-)
>>
>> any other in the list have opinion about this?
>
> There are very rare times when I've used one modifier that operates on
> the current optarg each time.
>
> For instance, a program that splits its logs, taking a -L (--level)
> modifier for each:
>
> ./foo -f /var/log/foo-panic.log -L3 -f /var/log/foo-normal.log -L1, etc
>
> However, I have not seen/done this in a really long time. But, in this
> case the value of the last -L passed modifies only the behavior of the
> previous -F option. The kludge needed to make this sane is ugly, I'm not
> sure why someone would do it deliberately unless they had to match what
> existed.
>
> I would agree with what you wrote as being standard behavior (I think
> POSIX has something to say about it too, I'll try to find the
> reference).

Again, the current behavior lets the application deal personally with
this case; while overriding multiple options would not make it possible,
I guess, without using further structures to accumulate options...  I
think the current behavior is more flexible...

--
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
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt