apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: RFC on interface change to apr_getopt_long()
Date Tue, 21 Nov 2000 08:19:14 GMT
On Tue, Nov 21, 2000 at 02:56:52AM -0500, Greg Hudson wrote:
> > Keep `val', but add const char *short_equivs, I meant.
> Okay, so I think the current proposal, with a little renaming to make
> everything simple and consistent, is:
> typedef struct apr_option_t {
>     /** long option name, or NULL if none */
>     const char *long_name;
>     /** short option letters, or NULL if none */
>     const char *short_names;

Plural? Is there a case where a long option has *more* than a single short
option letter? And even if we can find a case, I'm personally okay with
mandating that apr_getopt_long() doesn't support that behavior.

(and if somebody wants to force it, then they can use multiple apr_option_t
 records to specify the additional short options)

Hmm. -h -? --help are the same. Fine. One example. I still say that
switching that to 'char short_name' is a better API, as it reflects the more
common usage scenario (and encourages *single* short options for each long

> APR_DECLARE(apr_status_t) apr_getopt_long(apr_getopt_t *os,
>                                           const apr_option_t *opts,
>                                           int *optval, const char **optarg);
> Does this sound right to people?  I might or might not implement this
> before Fitz gets back from vacation; if not, I'll leave it on his
> plate. :)

Looks fine!


Greg Stein, http://www.lyra.org/

View raw message