apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "B. W. Fitzpatrick" <f...@red-bean.com>
Subject Re: RFC on interface change to apr_getopt_long()
Date Tue, 21 Nov 2000 08:31:41 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
> option).

Hmm. Yes, I think that putting a char* there is unnecessary. -h and -?
is the *only* example that I can think of where there would be more
than one.

-Fitz

Mime
View raw message