Re: Re: Gengetopt 2.21 enhancement suggestions

J. David Bryan wrote:
> 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.  :-)
> 

well, I meant how can you know which option went wrong :-)

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

you mean this way you can detect where the error is?

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

again you're right!  looks like I should study the documentation better 
(after having written it ;-)

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

well, actually, when I was thinking about enums I was thinking about 
ALSO storing values as enums, but probably this is not a good idea since 
also for strings such as "100" the enum literal 100 would not be 
correct...  Papp, since you proposed enums in the first place, could you 
please remind me what you meant for enums?  Having both string and enum 
values?

cheers
	Lorenzo

-- 
Lorenzo Bettini, PhD in Computer Science, DSI, Univ. di Firenze
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