Currently, one must path *both* a short-options string and an array of
apr_getopt_long_t structures to apr_getopt_long().
This seems redundant. If one's program supports long options, then
the long opts will need to be initialized anyway. In that case, any
given equivalent short opt ought to be initialized in the same place
as its matching long opt, so that the relationship between them is
clear.
By passing a short opts string *and* a long opts struct, the caller
redundantly redeclares the short options and whether they take args
(in the string, one uses colons; in the struct, one sets the `has_arg'
flag).
I have a feeling the current interface is due to the implementation:
since apr_getopt_long() falls back on apr_getopt() when it gets a
short option, callers of apr_getopt_long() are being asked to supply
the opt array for pass-thru to apr_getopt().
But between the `val' and `has_arg' fields in apr_getopt_long_t, the
caller has already specified everything unambiguously, and shouldn't
need to do it again in a short opts string.
PROPOSAL:
Let's make apr_getopt_long no longer take its `opts' argument.
Whatever implementation changes are necessary to make this work, I or
Brian Fitzpatrick can do (if he's interested).
Thoughts?
[Note on an unrelated issue: one might want *multiple* short options
corresponding to a given long option. The current system makes this
difficult to do, because currently each long opt can only name a
single equivalent short opt. Solving this would make the interface
more complicated, though, and I'm not sure it's worth it right now,
so I'm just noting this in passing.]
-Karl
For reference, from apr/include/apr_getopt.h:
/* structure representing a single longopt */
struct apr_getopt_long_t {
/** the name of the long argument (sans "--") */
const char *name;
/** 0 for no arg, 1 for arg */
int has_arg;
/** Either the short option char that this option corresponds to
* or a unique integer > 255
*/
int val;
};
/**
* Parse the options initialized by apr_initopt(), accepting long
* options beginning with "--" in addition to single-character
* options beginning with "-" (which are passed along to apr_getopt).
*
* Long options are accepted in both "--foo bar" and well as
* "--foo=bar" format
*
* End of argument processing if we encounter "--" or any option that
* doesn't start with "-" or "--".
*
* @param os The apr_opt_t structure returned by apr_initopt()
* @param opts A string of acceptable single-character options to the
* program. Characters followed by ":" are required to have
* an argument associated
* @param longopts A pointer to an array of apr_long_option_t structures, which
* can be initialized with { "name", has_args, val }. has_args
* is nonzero if the option requires an argument. A structure
* with a NULL name terminates the list
* @param optval The next option character parsed, or the value of "optval"
* from the appropriate apr_long_option_t structure if
* the next option is a long option.
* @param optarg The argument following the option, if any
* @tip There are four potential status values on exit. They are:
* <PRE>
* APR_EOF -- No more options to parse
* APR_BADCH -- Found a bad option character
* APR_BADARG -- No argument followed @parameter:
* APR_SUCCESS -- The next option was found.
* </PRE>
* @deffunc apr_status_t apr_getopt_long(apr_getopt_t *os, const char *opts, const apr_getopt_long_t *longopts, int *optval, const char **optarg) */
APR_DECLARE(apr_status_t) apr_getopt_long(apr_getopt_t *os,
const char *opts,
const apr_getopt_long_t *long_opts,
int *optval,
const char **optarg);
Received on Sat Oct 21 14:36:15 2006