Hi Bruno,
Bruno Haible wrote:
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.
I guess that we agree because your proposed new API:
1) fixes the problem for good by deprecating getopt_long and recommending
instead something that defines the options in one place.
2) implies some minor changes in the programs to adapt to the new
(simpler) interface.
The main difference I see between Arg_parser and your proposed API is that
Arg_parser is one level of abstraction higher. Arg_parser parses all the
options at once in a self-contained struct that can then be passed as
argument to other functions for further analysis. (Tarlz does this).
OTOH, getopt_long and your proposed API do not require dynamic memory
allocation, which may be an advantage in some cases.
(btw. what is the difference between ap_yes and ap_yme in Arg_parser?).
'ap_yes' means 'non-empty argument required'.
'ap_yme' means 'argument required, but it may be the empty string'.
'ap_yme' is not recommended, but is included for completeness.
Best regards,
Antonio.
