Re: reinterpret_cast<int&<( int* ) -- Odd behavior
On Apr 6, 9:54 am, "Alf P. Steinbach" <al...@start.no> wrote:
* joshuamaur...@gmail.com:
On Apr 3, 9:05 pm, blargg <blargg....@gishpuppy.com> wrote:
People seem to be getting confused with casts to a reference type.
Something like
reinterpret_cast<T&> (obj)
is nearly equivalent to
(*reinterpret_cast<T*> (&obj))
if that helps reason more clearly about it.
No. Just no. No at this entire thread.
That may be how it's implemented on some systems, and perhaps it is
interesting to try for fun, but to write any sort of real code, do not
do this.
I interpret the above as saying that the "nearly equivalent" is wrong in the
direction that any equivalence is merely how the particular implementation
does it, if it does.
And if that interpretation is correct, then your stance on that is
incorrect, because the standard /guarantees/ this equivalence in ?5.2.10/10.
So the original statement is wrong, but in the other direction: the word
"nearly" should be "exactly". :-)
Note that C++03 5.2.10/10 defines its behavior in terms of 5.2.10/7,
which is at best vague. It ends with "the result of such a pointer
conversion is unspecified".
5.2.10/7
A pointer to an object can be explicitly converted to a pointer to an object of different type.65) 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 unspecified.
It seriously says "yields the original pointer value" and "result
[...] unspecified" in the same line of text, referring, as far as I
can tell, to the same thing. I would like some clarity on this.
Let me again emphasize that for pretty much all code, if you're
writing a reinterpret_cast, or a C-style cast which cannot be replaced
with a static_cast, then your code probably has undefined behavior.
Agreed regarding the formal for portability.
However, to take a concrete example, in Windows programming you often have
to reinterpret_cast (or use a C style cast to do the same), because most of the
API routines' formal arguments are designed for C -- wrong types for C++!
It's in practice well defined behavior because it's defined by the system.
Any compiler that did something funny, even if allowed to do so by the standard,
would just not make it in the marketplace. So it's just formally undefined.
Yes. POSIX is guilty of this as well. You have to reinterpret_cast the
return of a dlsym, a void*, to a function pointer, undefined behavior
according to the C++ standard. In POSIX's defense, there isn't an
alternative in C, so I'm not calling this "bad" or "the wrong thing to
do" in C or C++. In this case yes, it's well defined by a standard,
the POSIX standard, just not the C standard or C++ standard.
reinterpret_cast has no defined behavior.
Again, sorry, but that's incorrect, even regarding the purely formal.
I exaggerated. It does have some well defined behavior, but people
commonly mistake exactly how little these guarantees are.
First of all, the standard guarantees in ?5.2.10/7 that round-trip
conversion of > pointers using reinterpret_cast yields the original pointer.
I noted above how this block from the standard is self contradictory.
Also, your interpretation disagrees with several other threads in
these forums in recent times.
For example, I recall a recent thread on here
http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/be1d6fd208dae05b/636f8ef3efad284a?lnk=raot
describing how pointers can have different sizes, how sizeof(char*)==8
and sizeof(int*)==4, and this is compliant with the standard. The
example as to why this is allowed and done is some hardware is only 64
bit addressable, but they want char* to point to smaller units than 64
bit units, so a char* contains the address of the 64 bit unit, and
contains an offset into that 64 bit unit of the 8 bit "char". This
basically means that a char* casted to an int* casted back to a char*
would not be the identity function on this hardware + compiler.
Thus I am left to ponder that thread versus an apparent schizophrenic
attempt to make this well defined in 5.2.10/7 and in the same breath
say unspecified.
Then -- but here we're up against an inconsistency in the standard -- in
?9.2/17 the standard guarantees that a pointer to a POD struct, suitably
converted via reinterpret_cast, points the struct's first member. This is
presumably in support of an old C technique for emulating inheritance. It's
useful for dealing with C interface that are based on such techniques.
The reason it is an inconsistency is that ?5.2.10/7 maintains that all other
reinterpret_cast pointer conversions than the roundtrip one, are
unspecified.
I don't see how you can get this reading. Then again, I see 5.2.10/7
as desperately needing cleanup. I believe the intent was to allow the
reinterpret_cast use for POD types as done in C, but otherwise still
subject to the strict aliasing rule. For example, I believe the intent
is to make the following well defined program which returns 5.
struct T { int x; };
struct U { int y; int z; };
int main()
{ T t;
t.x = 5;
U * u = reinterpret_cast<U*>(&t);
return u->y;
}
But, considering the potentially large amounts of code Out There(TM) that
relies on the ?9.2/17 guarantee, and also considering that a formally guaranteed
behavior can't be unspecified, it is IMHO ?5.2.10/7 that is in error.
As I understand the issues, I disagree. I think we can support the use
of reinterpret_cast in the C-style manual inheritance, and disallow
round trip conversions between arbitrary pointer types, and I think
that was the intent. Can we? Can we do this on bizarre architectures
where sizeof(char*) != sizeof(int*), etc.? 9.2/17 seems to indicate
that the following is well defined for all types T.
template <typename T>
struct foo
{ T x;
int y;
};
template <typename T>
T* getX(foo<T>& x)
{ return reinterpret_cast<T*>(&x); }
I think that's doable. It would mean that there would be a slight
pessimization for pointers to struct to be of the larger pointer kind
if its first member has a pointer of the larger pointer kind.
(Yes, casting to char* and unsigned char* is the exception. Casting
back to any other type is not. If you don't know what this exception
is, pretend I didn't say anything.)
I'm sorry, but casting to char* is, AFAIK, not formally an exception. One
might argue that it "should" be an exception because otherwise the only way to
copy a POD object to an array of char (or unsigned char) and back again would be
via memcpy, whose internal magic could then not be duplicated portably in a
user-defined routine. However, this ability is very strongly implied by
?9.2/17 mentioned above. It would take a perverse implementation to ignore the
non-normative note in that paragraph that it implies no padding at the start
of a POD struct, and do type-specific things. So, taking the stance that the
first member of a POD struct /could/ be a char, say, and reasonably assuming that
the implementation is not perverse in the sense outlined here, one has a
practical guarantee for char*, and indeed for any other POD type!
Summing up that logic:
* The formal guarantee for casting to char* is a myth.
* But ?9.2/17 implies an in-practice guarantee for any POD*.
3.8/5 strongly implies that static_casting from any pointer type to
void*, and then static_casting to char* or unsigned char* is defined
behavior.
3.9/2, as you noted, suggests being able to cast to char* or unsigned
char*, but it does not say this and uses memcpy in its example.
3.10/15, the strict aliasing rule, also strongly suggests being able
to access any object through a char* or unsigned char*.
3.9.2/4 has my strongest argument, which specifically singles out
void* as being able to point to any object, suggesting other pointers
cannot. It also states that char* and void* have the same
representation and alignment requirements, strongly suggesting char*
can also point at any object. I will also note that unsigned char* is
conspicuously absent here, which I assume is an oversight.
The standard is somewhat unclear on these issues, but as above, I
think the intent is that void*, char*, and unsigned char* are the
universal pointer types which can point at any object, and that all
other pointer types may not. Thus round-trip pointer casts not going
through void*, char*, or unsigned char* are undefined (or at best
unspecified) behavior. Finally, my point is that the issues with
reinterpret_cast are largely avoidable in practice using static_cast
and void* (though not with platform specific APIs like windows and
POSIX) (though type safety via forward declarations is better still).
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]