[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 Hudson <ghudson_at_MIT.EDU>
Date: 2000-11-21 22:44:57 CET

> Okay; +1 on `char short_name' instead of `char *short_names'. As
> Greg points out, for the rare exceptions, one can specify two
> apr_option_t structs.

> But, in that case, we don't need a short_name equiv field at all --
> we can just use the val field (as the code currently does), right?

The current code uses the val field for exactly one purpose:
determining what value to yield when a long option is matched.

I don't have any particular objection to overloading val to also be a
short name of the option, when it is a valid character. I just want
to be clear that that is a change.

With that change, we have (with yet more renaming):

typedef struct apr_option_t {
    /** long option name, or NULL if option has no long name */
    const char *name;
    /** option letter, or a value greater than 255 if option has no letter */
    int optch;
    /** nonzero if option takes an argument */
    int has_arg;
} apr_option_t;

APR_DECLARE(apr_status_t) apr_getopt_long(apr_getopt_t *os,
                                          const apr_option_t *opts,
                                          int *optch, const char **optarg);
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.