Stephen Boyd wrote:
> Is there an actual use case where someone needs to completely override
> get_value()? If you move this into the case statement then we get the
> generic error checking of get_value() with the benefits of being able to
> modify the context within a callback.
Yes, I like this idea.
> We could also probably use the
> return value of the low level callback to indicate whether or not to
> take some action after parsing the option. Perhaps something like
> quiting the option parsing loop when encountering such an option?
I'd rather not, since that would involve anticipating needs in advance.
This is meant to be a back door for ugly and unusual option types that
the mainstream API does not take care of yet. It seems best to allow
arbitrary effects.
[...]
>> -#define OPT_SHORT 1
>> -#define OPT_UNSET 2
[...]
>> +++ b/parse-options.h
>> @@ -40,8 +41,16 @@ enum parse_opt_option_flags {
>> PARSE_OPT_SHELL_EVAL = 256
>> };
>>
>> +enum parse_opt_ll_flags {
>> + OPT_SHORT = 1,
>> + OPT_UNSET = 2
>> +};
>> +
>
> I hope this isn't necessary.
Because of namespace or something else?
> This reminds me, we can probably simplify that "takes no value" error
> path in get_value() (see below).
Nice.
Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html