This is the mail archive of the
mailing list for the GCC project.
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote:
>> Well, I think it's in direct conflict with the C++ standard. If "X" is
>> a 32-bit pointer type, and "x" is a value of type X, "Y" is a 16-bit
>> pointer type, then:
>> is supposed to get you back the value of "x", but I don't see how that
>> can work, in general.
I made an error in the code above; I should have said "(X)(Y)x" since I
had already defined "X" and "Y" to be pointer types.
> Where in the standard does it say that?
A pointer to an object can be explicitly converted to a pointer to an
object of different type.13) Except that converting an rvalue of type
"pointer to T1" to the type "pointer to T2" (where T1 and T2 are
object types and where the alignment requirements of T2 are no
stricter than those of T1) and back to its original type yields the
original pointer value, the result of such a pointer conversion is
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.
Fundamentally, pointer types in C++ are compound types determined solely
by the pointed-to-type; what you're doing (by adding attributes to the
pointer) is adding a new operator for forming compound types. That's a
language extension, so it needs to be specified. It's not enough just
to tweak the back end to allow the mode attribute.
>> You only need two classes of pointers if you expect people to use
>> the second class in non-trivial expressions, i.e., dereference them,
>> perform pointer arithmetic on them, etc.
> Like the m16c, which lets you put additional less-frequently used data
> in function memory? Perhaps, a table of strings, or some CRC lookups?
If you really need two classes of pointers, then, sure, you need them.
All I did was ask whether or not you really need them and offer a
possible solution if you *don't* need them.
I am aware of "near" and "far" pointers in Borland (and other)
compilers. That's good news; you may have an example to help work
through the issues. That doesn't mean that there are no issues.
You seem to be trying to convince me that this is a simple thing and
that we should just do it and let the chips fall where they may. You
might be right -- but since almost every other such change has lead to
trouble, I'm not inclined to take chances. Please do the work up front
to specify how this interacts with all aspects of the language. That's
user documentation we need anyhow.
I do think this sounds like a useful feature.
(650) 331-3385 x713