[comp.lang.c] const void *

andy@cit-vax.Caltech.Edu (Andy Fyfe) (04/21/88)

What does (or should?) the ANSI standard say about const void *?

My intuition says that, so far as conversions without an explicit
cast go, the following should be legal:

	any *		<-->	void *
	const any *	<-->	const void *
	any *		 -->	const void *
	const any *	<--	void *

Or, void * is the generic pointer, and const is treated separately
as an attribute that can be added but not taken away (without an
explicit cast).  Is this the way it is supposed to work?

If plain "void *" is to be the generic pointer, is K&R 2 correct
in defining memcmp as
	int memcmp(const void *, const void *, size_t)
or fwrite as
	size_t fwrite(const void *, size_t, size_t, FILE *)
for example?

Also, should "const any * --> void *" be allowed, since "void *"
is the generic pointer?
-- 
Andy Fyfe
            andy@csvax.caltech.edu
            wjafyfe@caltech.bitnet
            andy@cit-vax.UUCP	(...!ames!elroy!cit-vax!andy)

andy@cit-vax.Caltech.Edu (Andy Fyfe) (04/26/88)

In article <6214@cit-vax.Caltech.Edu> andy@cit-vax.UUCP (Andy Fyfe) writes:
>What does (or should?) the ANSI standard say about const void *?

The reason I wondered about this:  Gnu C wants to be follow the rules
according to ANSI.  The current interpretation says that "void *"
is the generic pointer, so it allows
	any *		<-->	void *
	const any *	<-->	void *
and gives warnings for
	const any *	<-->	const void *
	any *		<-->	const void *
("any" here means any type other than "void".)  RMS seems quite willing
to make gcc conform to the rules.

This has so far given me errors under 2 circumstances.  The first occured
when trying to compile Henry Spencer's string functions.  The second occurs
when using function prototypes that use "const void *" (like fwrite, etc.).

As an aside, K&R 2 (section 7.8.5) makes it clear that the pointer returned
by malloc must explicitly be cast to the correct pointer type.  Why is this
required, given that malloc returns a "void *"?
-- 
Andy Fyfe
            andy@csvax.caltech.edu
            wjafyfe@caltech.bitnet
            andy@cit-vax.UUCP	(...!ames!elroy!cit-vax!andy)

karl@haddock.ISC.COM (Karl Heuer) (04/30/88)

In article <6268@cit-vax.Caltech.Edu> andy@csvax.caltech.edu (Andy Fyfe) writes:
>What does (or should?) the ANSI standard say about const void *?

Should say: All conversions between (any *) and (void *), with arbitrary type
qualifiers on either, are legal operations; but converting from const to non-
-const or from (void *) to any pointer type other than (void *) or (char *),
except by means of an explicit cast, is a Common Warning.

Does say: Something too restrictive, as Dennis has pointed out.  Has this been
resolved yet, Doug?

>As an aside, K&R 2 (section 7.8.5) makes it clear that the pointer returned
>by malloc must explicitly be cast to the correct pointer type.  Why is this
>required, given that malloc returns a "void *"?

Probably to avoid the Common Warning.  The compiler doesn't know that the
result of malloc is maximally aligned; (void *) generally isn't.

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

gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/30/88)

In article <3723@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes:
>Does say: Something too restrictive, as Dennis has pointed out.
>Has this been resolved yet, Doug?

Yes, the rules for conversion from/to qualified types, particularly by
simple assignment, are being changed to reflect the original intent.
I haven't seen the final form of the words, but I think they will say
something to the effect that qualified and non-qualified types may be
freely interconverted and only an attempt to access storage that
somewhere along the way was at least temporarily qualified is constrained
by the qualifier.