From kfogel@galois.collab.net Tue Nov 21 21:49:32 2000 Return-Path: Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Delivered-To: mailing list dev@apr.apache.org Received: (qmail 3071 invoked from network); 21 Nov 2000 21:49:32 -0000 Received: from 24-148-31-194.na.21stcentury.net (HELO galois.collab.net) (root@24.148.31.194) by locus.apache.org with SMTP; 21 Nov 2000 21:49:32 -0000 Received: (from kfogel@localhost) by galois.collab.net (8.10.1/8.10.1/Debian 8.10.1-1) id eALJXpm13772; Tue, 21 Nov 2000 13:33:51 -0600 To: Greg Hudson Cc: dev@apr.apache.org, dev@subversion.tigris.org Subject: Re: RFC on interface change to apr_getopt_long() References: <200011212144.QAA06703@egyptian-gods.MIT.EDU> Reply-To: kfogel@collab.net Emacs: more boundary conditions than the Middle East. From: Karl Fogel Date: 21 Nov 2000 13:33:51 -0600 In-Reply-To: Greg Hudson's message of "Tue, 21 Nov 2000 16:44:57 -0500" Message-ID: <87hf51glwg.fsf@galois.collab.net> Lines: 28 X-Mailer: Gnus v5.7/Emacs 20.6 X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Greg Hudson writes: > 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. Totally. > 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); +1. -K