You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@bellsouth.net> on 2000/08/09 18:43:58 UTC
Re: cvs commit: apache-2.0/src/lib/apr/misc/unix getopt.c
wrowe@locus.apache.org writes:
> wrowe 00/08/09 07:54:04
>
> Modified: src/lib/apr/include apr_getopt.h
> src/lib/apr/misc/unix getopt.c
...
> + * @deffunc apr_status_t apr_getopt(apr_getopt_t *os, const char *opts, char *optch, char **optarg)
This doc doesn't match the current signature of apr_getopt() (but see
note below)...
> */
> -APR_EXPORT(apr_status_t) apr_getopt(apr_int32_t nargc, char *const *nargv,
> - const char *ostr, apr_int32_t *rv,
> - apr_pool_t *cont);
> +APR_EXPORT(apr_status_t) apr_getopt(apr_getopt_t *os, const char *opts,
> + char *optch, char const** optarg);
>
> #endif /* ! APR_GETOPT_H */
About the signatures of apr_getopt() and apr_initopt()... Are the
types of the last parameter to each function convenient to the caller?
We now get these warnings with gcc (-Wall -Wstrict-prototypes and whatever
else maintainer mode brings):
2a3,4
> http_main.c: In function `main':
> http_main.c:321: warning: passing arg 4 of `apr_initopt' from incompatible pointer type
4a7,9
> ab.c: In function `main':
> ab.c:1010: warning: passing arg 4 of `apr_initopt' from incompatible pointer type
> ab.c:1011: warning: passing arg 4 of `apr_getopt' from incompatible pointer type
I could play around with argv and optarg in http_main.c and ab.c, but
that seems to be missing the point since argv and optarg are already
declared in the obvious way.
Have fun,
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
RE: cvs commit: apache-2.0/src/lib/apr/misc/unix getopt.c
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> -----Original Message-----
> From: Jeff Trawick [mailto:trawickj@bellsouth.net]
> Sent: Wednesday, August 09, 2000 3:20 PM
>
> > I guess the question is, are command line arguments mutable?
>
> I think the answer is no, but that the follow-up question is more
> interesting: "can we express and enforce this immutability via the C
> language without it hindering the caller?" I think the answer to this
> one may be no as well.
With the caviat that MSVC is ignoring/not generating several types
of warnings.... here is the patch to make the stuff compile well on my
machine:
Index: lib/apr/include/apr_getopt.h
===================================================================
RCS file: /home/cvs/apache-2.0/src/lib/apr/include/apr_getopt.h,v
retrieving revision 1.17
diff -u -r1.17 apr_getopt.h
--- lib/apr/include/apr_getopt.h 2000/08/09 18:00:15 1.17
+++ lib/apr/include/apr_getopt.h 2000/08/09 20:51:26
@@ -73,7 +73,7 @@
* @param argc The number of arguments to parse
* @param argv The array of arguments to parse
* @tip Arguments 2 and 3 are most commonly argc and argv from main(argc, argv)
- * @deffunc apr_status_t apr_initopt( apr_getopt_t **os, apr_pool_t *cont,int argc, char const* const* argv)
+ * @deffunc apr_status_t apr_initopt(apr_getopt_t **os, apr_pool_t *cont, int argc, char const* const* argv)
*/
APR_EXPORT(apr_status_t) apr_initopt(apr_getopt_t **os, apr_pool_t *cont,
int argc, char const* const* argv);
@@ -93,10 +93,10 @@
* APR_BADARG -- No argument followed @parameter:
* APR_SUCCESS -- The next option was found.
* </PRE>
- * @deffunc apr_status_t apr_getopt(apr_getopt_t *os, const char *opts, char *optch, char const** optarg)
+ * @deffunc apr_status_t apr_getopt(apr_getopt_t *os, const char *opts, char *optch, const char **optarg)
*/
APR_EXPORT(apr_status_t) apr_getopt(apr_getopt_t *os, const char *opts,
- char *optch, char const** optarg);
+ char *optch, const char **optarg);
#endif /* ! APR_GETOPT_H */
Index: lib/apr/misc/unix/getopt.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/lib/apr/misc/unix/getopt.c,v
retrieving revision 1.20
diff -u -r1.20 getopt.c
--- lib/apr/misc/unix/getopt.c 2000/08/09 17:46:21 1.20
+++ lib/apr/misc/unix/getopt.c 2000/08/09 20:51:26
@@ -49,7 +49,7 @@
}
APR_EXPORT(apr_status_t) apr_getopt(apr_getopt_t *os, const char *opts,
- char *optch, char const** optarg)
+ char *optch, const char **optarg)
{
const char *p;
const char *oli; /* option letter list index */
Index: support/ab.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/support/ab.c,v
retrieving revision 1.25
diff -u -r1.25 ab.c
--- support/ab.c 2000/08/09 15:01:59 1.25
+++ support/ab.c 2000/08/09 20:51:29
@@ -193,9 +193,9 @@
time_t aprtimeout = 30 * APR_USEC_PER_SEC; /* timeout value */
int use_html = 0; /* use html in the report */
-char *tablestring;
-char *trstring;
-char *tdstring;
+const char *tablestring;
+const char *trstring;
+const char *tdstring;
int doclen = 0; /* the length the document should be */
int totalread = 0; /* total number of bytes read */
@@ -937,7 +937,7 @@
/* read data to POST from file, save contents and length */
-static int open_postfile(char *pfile)
+static int open_postfile(const char *pfile)
{
apr_file_t *postfd = NULL;
apr_finfo_t finfo;
@@ -974,7 +974,7 @@
char tmp[1024];
apr_status_t status;
apr_getopt_t *opt;
- char *optarg;
+ const char *optarg;
char c;
/* table defaults */
RE: cvs commit: apache-2.0/src/lib/apr/misc/unix getopt.c
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Jeff Trawick [mailto:trawickj@bellsouth.net]
> Sent: Wednesday, August 09, 2000 3:20 PM
>
> "William A. Rowe, Jr." <wr...@lnd.com> writes:
>
> > My problem, I can't get MSVC to complain (even at max error level
> > rejection), so I don't know when/if I've licked the problem. Jeff,
> > if you have a fix, please apply and make the doc consistant.
>
> I suspect that the "fix" is to avoid the const on the last parm to both
> apr_getopt() and apr_initopt().
That feels "wrong" to me. While in general, K&R declares that *argv[]
isn't const, I think it's simply bad form to maul the source parameters,
especially when we have a proper memory pool handler to create/discard
these sorts of working spaces.
> I realize that this is ugly in the const-ness sense, but IMHO if the
> normal declaration of argv ("char **argv" or "char *argv[]") can't be passed
> to apr_initopt() then it is apr_initopt() that is broken.
Wait... you can always pass non-const to const functions, simply not the
other way around. We can pass the stock argv to apr_initopt, the question
is will we mutilate it in place. If so, the original patch needs to be
changed to entirely non-const, and if not, it's a tweak.
> > This might be the fix, again I can't be certain:
> >
> > * @deffunc apr_status_t apr_getopt(apr_getopt_t *os, const
> char *opts, char *optch, const char **optarg)
> > */
> > APR_EXPORT(apr_status_t) apr_getopt(apr_getopt_t *os, const
> char *opts,
> > char *optch, const char
> > **optarg);
>
> No... Then I have to specify "const char *optarg" in ab.c and then I
> have to cast optarg later when passing it to other routines.
That's actually the desired declaration of optarg. Yes, you can maul
it with a cast, and yes, you can copy it out to something useful, but
I recall this conversation about another generic c lib function, and
there is no good resolution.
> (Don't forget the "problem" with apr_initopt().)
Ok... If we otherwise can accept this patch, the q. on the floor is this:
Do we want to treat argv as const? Or do we choose to maul argv?
Responses? (I'm in the former camp, but I won't even push a vote either way.)
Bill
Re: cvs commit: apache-2.0/src/lib/apr/misc/unix getopt.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
"William A. Rowe, Jr." <wr...@lnd.com> writes:
> I guess the question is, are command line arguments mutable?
I think the answer is no, but that the follow-up question is more
interesting: "can we express and enforce this immutability via the C
language without it hindering the caller?" I think the answer to this
one may be no as well.
> If so, all the constness is mute. If not, it may not be convienient,
> but the types should hold up (note - const'ness is one of my several
> weak points, should go back and read my K&R again, but constness of
> type** always gives me a headache.)
The headache comes from the language I'm afraid.
> My problem, I can't get MSVC to complain (even at max error level
> rejection), so I don't know when/if I've licked the problem. Jeff,
> if you have a fix, please apply and make the doc consistant.
I suspect that the "fix" is to avoid the const on the last parm to both
apr_getopt() and apr_initopt().
I realize that this is ugly in the const-ness sense, but IMHO if the
normal declaration of argv ("char **argv" or "char *argv[]") can't be passed
to apr_initopt() then it is apr_initopt() that is broken.
> This might be the fix, again I can't be certain:
>
> * @deffunc apr_status_t apr_getopt(apr_getopt_t *os, const char *opts, char *optch, const char **optarg)
> */
> APR_EXPORT(apr_status_t) apr_getopt(apr_getopt_t *os, const char *opts,
> char *optch, const char
> **optarg);
No... Then I have to specify "const char *optarg" in ab.c and then I
have to cast optarg later when passing it to other routines.
(Don't forget the "problem" with apr_initopt().)
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
RE: cvs commit: apache-2.0/src/lib/apr/misc/unix getopt.c
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
Well,
I guess the question is, are command line arguments mutable?
If so, all the constness is mute. If not, it may not be convienient,
but the types should hold up (note - const'ness is one of my several
weak points, should go back and read my K&R again, but constness of
type** always gives me a headache.)
My problem, I can't get MSVC to complain (even at max error level
rejection), so I don't know when/if I've licked the problem. Jeff,
if you have a fix, please apply and make the doc consistant.
This might be the fix, again I can't be certain:
* @deffunc apr_status_t apr_getopt(apr_getopt_t *os, const char *opts, char *optch, const char **optarg)
*/
APR_EXPORT(apr_status_t) apr_getopt(apr_getopt_t *os, const char *opts,
char *optch, const char **optarg);
Bill
> -----Original Message-----
> From: Jeff Trawick [mailto:trawickj@bellsouth.net]
> Sent: Wednesday, August 09, 2000 11:44 AM
> To: new-httpd@apache.org
> Subject: Re: cvs commit: apache-2.0/src/lib/apr/misc/unix getopt.c
>
>
> wrowe@locus.apache.org writes:
>
> > wrowe 00/08/09 07:54:04
> >
> > Modified: src/lib/apr/include apr_getopt.h
> > src/lib/apr/misc/unix getopt.c
> ...
> > + * @deffunc apr_status_t apr_getopt(apr_getopt_t *os,
> const char *opts, char *optch, char **optarg)
>
> This doc doesn't match the current signature of apr_getopt() (but see
> note below)...
>
> > */
> > -APR_EXPORT(apr_status_t) apr_getopt(apr_int32_t nargc,
> char *const *nargv,
> > - const char *ostr,
> apr_int32_t *rv,
> > - apr_pool_t *cont);
> > +APR_EXPORT(apr_status_t) apr_getopt(apr_getopt_t *os,
> const char *opts,
> > + char *optch, char
> const** optarg);
> >
> > #endif /* ! APR_GETOPT_H */
>
> About the signatures of apr_getopt() and apr_initopt()... Are the
> types of the last parameter to each function convenient to the caller?
> We now get these warnings with gcc (-Wall -Wstrict-prototypes
> and whatever
> else maintainer mode brings):
>
> 2a3,4
> > http_main.c: In function `main':
> > http_main.c:321: warning: passing arg 4 of `apr_initopt'
> from incompatible pointer type
> 4a7,9
> > ab.c: In function `main':
> > ab.c:1010: warning: passing arg 4 of `apr_initopt' from
> incompatible pointer type
> > ab.c:1011: warning: passing arg 4 of `apr_getopt' from
> incompatible pointer type
>
> I could play around with argv and optarg in http_main.c and ab.c, but
> that seems to be missing the point since argv and optarg are already
> declared in the obvious way.
>
> Have fun,
>
> --
> Jeff Trawick | trawick@ibm.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>