[sheepdog] [PATCH 3/6] introduce sd_getopt as an alternative to getopt_long

[Liu Yuan]

On 11/05/2012 11:29 PM, MORITA Kazutaka wrote:
>> > Is this flags for check necessary? We already set 'type' of parameter at
>> > the very beginning (at sd_opt_param struct), so we can do type check at
>> > the parse phase and throw error message when meeting invalid parameters.
>> > So when we call sd_opt_param_get(), we should get what we specify at
>> > sd_opt_param struct and no need to check type after calling this function.
> I tried the similar type check first, but I found that --snapshot
> option of 'collie vdi xxx' allows both number and string; if optarg is
> number, vdi_parser regards it as a snapshot id, and otherwise, the
> function regards it as a snapshot tag.  So vdi_parser needs to know
> how parse_sd_opt_value() parsed the arugment, and that's the reason I
> gave up doing the type check in option.c.

For this case, I think both number and string can be first interpreted
as string at sd_opt level. 'collie vdi xxx' command can optionally to do
further operations for proper checks.

> 
> Another idea I came up with was setting expecting types by or'ing
> SD_OPT_XXX values, and receiving the parsed types as a result.
> parse_sd_opt_value returns error if it fails in parsing the argument
> as none of the expected types.  How do you think about this?
> 
>> > 
>> > Maybe we can even do range check for 'size' at parse time by built-in
>> > 'min' 'max' information at sd_opt_param struct.
> I also tried this, but gave up because this makes sd_opt_param
> complicated.  But if you prefer this, I don't mind implementing it.
> 

I am okay to leave the range check outside core for minimal implementation.

Thanks,
Yuan