Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!ico!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.std.c
Subject: Re: the "const" qualifier
Message-ID: <17194@haddock.ima.isc.com>
Date: 1 Aug 90 16:40:21 GMT
References: <1990Aug1.005200.21645@ccu.umanitoba.ca>
Reply-To: karl@kelp.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 32

In article <1990Aug1.005200.21645@ccu.umanitoba.ca> rpjday@ccu.umanitoba.ca writes:
>Section 3.5.3, line 26, we have, "For two qualified types to be
>compatible, both shall have the identically qualified version of a
>compatible type..."  Does "compatible" mean assignment compatible?

No, it means that they really are the exact same type, or could be after
completion.  For example, "void (*f[3])()" and "void (*f[])(double)" are
compatible types, because each can be completed to "void (*f[3])(double)"
(known as the _composite type_).  See 3.1.2.6.

>[deleted stuff that was based on the wrong assumption]
>  Finally, line 12 of 3.5.3, "If an attempt is made to modify an object
>defined with a const-qualified type through use of an lvalue with
>non-const-qualified type, the behavior is undefined."  How would one
>do this anyway?

You can remove const-qualification by using an explicit cast.
	int const i = 10;
	int *p = (int *)&i;
	*p = 20;
The cast itself is legal (though certainly questionable).  The assignment to
`*p' is legal syntactically but not semantically.

Another example is
	extern char const buf[];
	char *p = strchr(buf, c);
where the cast is hidden inside the implementation of strchr().  Logically,
the return type of strchr() is the same as its first actual argument (either
`char const *' or `char *'), but C has no way to declare that.  A similar
problem exists with functions like `memcpy()'.  Caveat emptor.

Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint