apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Fogel <kfo...@galois.collab.net>
Subject Re: RFC on interface change to apr_getopt_long()
Date Tue, 21 Nov 2000 17:14:22 GMT
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. :)

Mime
View raw message