Hi Antonio,
> I think that it would be better to fix the problem for good by deprecating
> getopt_long and recommending instead something that defines the options in
> one place, as Arg_parser does. Even if this implies some minor changes in
> the programs to adapt to the new (simpler) interface.
Thanks for the suggestion. But in fact, it's only the API of getopt_long()
that is problematic. Its inner workings are fine. And in order not to add
much extra binary code size to programs on GNU systems, I think it's
reasonable to keep using getopt_long() under the hood.
> See this fragment of main.c from GNU ed showing how it defines the options
> for Arg_parser:
>
> const ap_Option options[] =
> {
> { 'E', "extended-regexp", ap_no },
> { 'G', "traditional", ap_no },
> { 'h', "help", ap_no },
> { 'l', "loose-exit-status", ap_no },
> { 'p', "prompt", ap_yes },
Thanks for the pointer to Arg_parser. These is indeed some commonality:
<getopt.h> <argp.h> carg_parser
struct option argp_option ap_Option
const char *name; const char *name; const char *long_name;
int key; int code;
int has_arg; flags & OPTION_ARG_OPTIONAL ap_Has_arg has_arg;
int *flag;
int val; (overloaded)
The no_argument / required_argument / optional_argument part of <getopt.h>
is fine. I see no reason to replace that with different names (btw.
what is the difference between ap_yes and ap_yme in Arg_parser?).
Bruno
