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. :-)
...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").
Actually setting print_errors to 0 in the _init function causes previous
code not to work anymore in some cases, and this is quite dangerous
(e.g., some tests in the testsuite do not print error messages anymore);
thus I set print_errors to 1 also in the _init function and changed the
documentation accordingly.
After all, the aim of this structure is to make code using the generated
parser "resistant" to future enhancements to that structure, so I think
this is the safest solution :-)
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
_______________________________________________
Help-gengetopt mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-gengetopt
