Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!hellgate.utah.edu!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.std.c
Subject: Re: Rationale for allowing const T* = T* wanted.
Message-ID: <10034@dog.ee.lbl.gov>
Date: 19 Feb 91 10:44:03 GMT
References: <3913@lupine.NCD.COM>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 38
X-Local-Date: Tue, 19 Feb 91 02:44:03 PST

In article <3913@lupine.NCD.COM> rfg@lupine.ncd.com (Ron Guilmette) writes:
>I have been stirring up trouble in x3j16 [regarding const]

Good :-)

In my opinion, the entire const/non-const setup in ANSI C is wrong.
(I am not entirely happy with it in C++ either, but note that the notion
of `const' is fairly different in the two languages.)

There is something fundamentally `bad' about the fact that, for instance,
a strchr() function must cast a const-pointer to a non-const pointer:

	char *strchr(const char *str, int c0) {
		char c = c0, sc;
		for (; *str != c; str++)
			if (*str == '\0')
				return (NULL);
		return ((char *)str);
	}

In effect, strchr() can be used to `dequalify' a pointer:

	const char *ccp;
	char *cp;

	cp = strchr(ccp, *ccp);	/* dequalify */

If the language is going to provide type checking, strchr() should be
a function of `optionally-const char *' returning `typeof arg1'.
Since it is not, and since example like strchr() are rather more
frequent than I originally expected, I would rather it did not even
pretend to provide such checking.  I believe things would be `better'
if the language freely allowed conversion between `char **' and
`const char **' and `char * const *' and `const char * const *', for
instance.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov