[help-gengetopt] Re: Gengetopt 2.21 enhancement suggestions

[J. David Bryan]

Hi Lorenzo,


On 15 Oct 2007 at 14:49, Lorenzo Bettini wrote:

> > The attached "gengetopt-2.21-enh-2.diff" suggests an implementation.
> 
> OK, but, in case, how can someone understand if there's actually an 
> error...

By checking the return value from the parser.  :-)


> ...and print the corresponding error message? 

If we are setting "print_errors" to 0, then we don't want the error message 
from "getopt_long" but instead want to take some other action.  That action 
would be indicated by checking optarg, optind, optopt, etc. after the 
parser returns an error value.


> by the way, the print_errors field should default to '1' to be backward
> compliant

I believe the patch has "print_errors" default to 1 everywhere except in 
"cmdline_parser_params_init", where it is set to 0 because the manual says 
it should be ("...returns a dynamically allocated structure with all fields 
initialized to 0").


> do you think using enum values would solve also the argtype issue?

I think it would be easier than using strings (conversion to the actual 
values needed could be done with an array lookup, for example), but I think 
being able to use the values directly (as integers, floats, etc.) would be 
best.


> I'm asking because adding enum values would be quite simple, while
> adding types to values would require some more time (it could be done
> anyway) 

I think that if you used syntax that could be generalized later, it would 
be OK to start with enums and add other types later.  That is, allow an 
optional "argtype" that defaults to "string" (for backward compatibility), 
and restrict specification to "enum" or "string".  Then if you add "int", 
"float", etc. later, you don't need to change the syntax.

  
> thanks for the patches!

You're welcome.

                                      -- Dave