[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: Greg Stein <gstein_at_lyra.org>
Date: 2000-11-21 09:19:14 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).

>...
> 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!

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
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.