httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: util_xml.c has constification warnings.ry
Date Mon, 03 Jul 2000 09:20:17 GMT
On Mon, Jul 03, 2000 at 11:03:48AM +0200, Sascha Schumann wrote:
> On Mon, 3 Jul 2000, Greg Stein wrote:
>...
> > The only reason that we have the ap_strchr_c() is because the Single Unix
> > Spec is broken. It gives back a writable string when you feed it an
> > *unwriteable* one. In other words, it is dropping the const and it really
> > shouldn't. 
> 
> Your analysis is implying that you can pass only read-only
> strings to strchr. This is false.
> 
> The prototype was written that way to avoid casts. Imagine this:
> 
>     char buf[256];
>     char *p;
> 
>     sprintf(buf, "for");
>     p = strchr(buf, 'f');
>     if (p) *p = 'x';
> 
> With your proposed change, the fifth line would need to be
> rewritten as:
> 
>     p = (char *) strchr(buf, 'f');
> 
> A 'const' declarator in a parameter declaration does not mean
> that the respective argument must be a read-only object. It means
> that the function may not alter that argument. That is why
> ap_strchr_c should return a value of type char *.

Slow down there, Tex. The Single Unix Spec is broken in the sense that it
loses the const when we don't want it to. Sure, the *spec* is written that
way to enable your scenario. But that isn't what we want in Apache. We want
it to be as tight as possible.

This "looseness" in strchr() and strstr() turned up two "problems" in the
DAV code that was just added. Just declaration problems rather than true
"oops, I tried to modify a truly constant string", but I consider them
problems none-the-less. With Ryan's bread crumb for the right path, I
tracked them all(?) down.

For Apache, we have two functions:

char * ap_strchr(char *, int)
const char * ap_strchr_c(const char *, int)

Use the right one for the job.

Cheers,
-g

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

Mime
View raw message