Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!jarthur!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: const vs. void
Message-ID: <71515@microsoft.UUCP>
Date: 25 Mar 91 20:44:04 GMT
References: <1991Mar20.164518.19928@intelhf.hf.intel.com>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 33

In article <1991Mar20.164518.19928@intelhf.hf.intel.com> ajw@watson.hf.intel.com writes:

>It's as if a 'void *' will accept any pointer, const or no.
>Is this right?

ARM page 36 says:

"A pointer to any non-const and non-volatile object type may be converted
to a void*."

Many people would interpret this as a prohibition from compilers accepting
an implicit conversion of a pointer to a const or volatile to a void*.
I do not consider it such a prohibition,  but rather a statement of 
permission.  If the ANSI-C++ committee defines such a conversion to be a 
constrained error [a error compilers are required to detect] then such 
is truly "illegal."  Until if-and-when the ANSI-C++ committee defined 
this [and any other thing] as a constrained error, all we can say is that 
it is "implementation dependent."

This is a general problem with the ARM.  Since it is a reference manual,
not a specification, it tends to state those things that a C++ programmer
is allowed to do, and tends not to state those things that a C++
compiler is required to reject.  Hopefully, the ANSI-C++ committee will
make it "clear" what compilers are required to reject, in a manner 
similar to the ANSI-C specification's "constraints."

PS:

Even if there is a specification stating what compilers are required
to accept, and what they are required to reject, there still remains
a gray area of "implementation dependent" code where compilers are allowed
to accept or reject the code, and generate something sensible or not in the 
process.