On Mon, Nov 27, 2000 at 11:17:01AM -0600, Karl Fogel wrote: > [EMAIL PROTECTED] 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.) Historical. > Okay. I withdraw my (only implied) +1 on adding the consts. :-) yes/no/yes/no. Fickle, fickle boy :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
