[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC on interface change to apr_getopt_long()

From: B. W. Fitzpatrick <fitz_at_red-bean.com>
Date: 2000-11-21 09:31:41 CET

> 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
Received on Sat Oct 21 14:36:15 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.