This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: does gcc support multiple sizes, or not?

DJ Delorie wrote:
>> The "except that" sentence implies the statement above, assuming
>> that the pointed-to type does not have stricter alignment.  So, if
>> casting a 32-bit pointer to int to a 16-bit pointer to char and back
>> does not always yield the same value, then something has to give.
> reinterpret_cast doesn't require that the intermediate form have the
> same bit pattern.

Exactly so.  However, all valid pointers must be handles, so unless the
32-bit address space is "sparse", something will go wrong.

> The way I read it, "a pointer" to an object can be converted to "a
> pointer" to a different type of object, but as reinterpret_cast
> already leaves the const qualifier alone, it seems to be focusing on
> the object's type, not the pointer's type.

There's no distinction in ISO C++; every object type has exactly one
associated pointer type.  The point of reinterpret_cast is to let you
convert A* to B* where A and B are unrelated object types.  It's an
operation on pointers, not general objects; for example, you can't do
"reinterpret_cast<double>(7)", but you can do

> If you say C++ doesn't support them, I'll take it out and make it
> obvious that C++ doesn't support them, as long as C still supports
> them (because I use that feature a lot).  I just don't want it to
> crash when the user does something that appears to be legal based on
> the gcc manual.

Good call.  I don't feel qualified to comment for C, but for C++, I
think it's correct to say that we don't support them.  I think we
*could* support them, in theory, but that would be a good bit of work.

Mark Mitchell
(650) 331-3385 x713

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]