apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr/threadproc/win32 proc.c
Date Mon, 27 Nov 2000 21:11:25 GMT
On Mon, Nov 27, 2000 at 11:17:01AM -0600, Karl Fogel wrote:
> rbb@covalent.net writes:
> > We are asking for data that is const char * const *, but passing in
> > char * const * data.  This causes incompatible pointer type warnings when
> > compiling Apache.
> In that case, it seems appropriate to cast the data being passed in --
> adding more const is always okay.

Yup, totally okay. And in many cases, that data is *already* const; removing
the const to be compatible with "char * const *" is REALLY bad.

> > APR is actually not complaining, but it does seem a bit odd to me that we
> > are asking for stricter access than the underlying functions we are
> > using.  One of the arguments made for this commit was that we may actually
> > get const data, so we had better be sure that we treat it as const.  I
> > disagree.  If we are given const data, then we have a problem, because
> > POSIX doesn't state that the C Run-Time won't change the data underneath
> > us.
> > 
> > We NEED to match POSIX in this, and require char *const * data.
> Ah, yes.  If the underlying functions aren't promising that, then we
> can't either.  Too bad.

It isn't "promising" it solely for historical reasons. It *does* have to
promise it for the reasons in my previous mail. You'd get segfaults if it
didn't treat the strings as const.

> (Somehow I suspect that they never do change the data, and that their
> prototypes are just because someone was being loose, but we can't know
> that with certainty, I suppose.)


> Okay.  I withdraw my (only implied) +1 on adding the consts. :-)

yes/no/yes/no. Fickle, fickle boy :-)


Greg Stein, http://www.lyra.org/

View raw message