[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: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-11-21 18:14:22 CET

Yup! That's exactly what was in my brain too.

For now in the client, I'll work with the current getopt_long; no need
to be making two changes at once. Whenever the APR change happens (as
soon as you like, or maybe I'll beat you to it :-) ), we can update
the client, it should be trivial.

APR developers: any objections, comments? I believe Subversion is the
only user of apr_getopt_long() at the moment.

-K

Greg Hudson <ghudson@MIT.EDU> writes:
> 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;
> /** nonzero if option takes an argument */
> int has_arg;
> /** result to yield when this option is specified */
> int optval;
> } apr_option_t;
>
> 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. :)
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.