Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!paperboy!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: ANSI C standard library
Message-ID: <16053@smoke.brl.mil>
Date: 3 May 91 20:47:26 GMT
References: <114913@tut.cis.ohio-state.edu> <1991May1.170750.19222@zoo.toronto.edu> <116105@tut.cis.ohio-state.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 26

In article <116105@tut.cis.ohio-state.edu> meranda@iguana.cis.ohio-state.edu (deron meranda) writes:
>Concerning strchr() and const char *'s...
>It appears as if you are correct.  The Rationale 3.3.4 clearly
>states that a (const char *) may be typecast to a (char *).
>However, it also appears that one can not even dereference the
>resulting pointer, whether or not the object is modified
>(actually the behavior is undefined).

As I recall the constraints, you can certainly access the pointer-to
object for reading, and unless the actual object itself is const-
qualified, you can also access it for writing.  The "const" in a
"const char *" parameter does NOT mean that the pointed-to chars
have to be read-only; rather, it means that the function cannot use
that parameter to modify them.

I see no problem in implementing strchr() using strictly conforming code:

char *strchr( const char *s, int c )
	{
	do
		if ( *s == (char)c )
			return (char *)s;
	while ( *s++ != '\0' );

	return (char *)0;
	}