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