Re: reinterpret_cast<int&<( int* ) -- Odd behavior
* joshuamaurice@gmail.com:
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".
It only appears vague when the rest of the sentence is omitted, as you do.
;-)
See below.
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.
OK.
The key word is the /except/, at the start of the sentence.
/Except/ for round-trip conversion of pointers with suitably aligned
referents,
the result of converting a pointer is, according to this paragraph,
unspecified.
And that's very very clear.
However, as I explained in the article you're replying to here, the standard
is
inconsistent, because in ?9.2/17 it does define an additional conversion
which,
being well-defined, cannot be unspecified. And there the alignment isn't
implicit in the types but is a property of the particular objects pointed
to.
Ensured by one of those objects being located at the start of POD struct,
and
the other being that POD struct.
[snip]
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.
Yes.
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.
I'm sorry, your argument for self-contradiction is incorrect, based on
ignoring
the relevant lead-in part of the sentence from which you lifted the last
words,
namely, ignoring the important formulation "except". As explained above.
However, I noted in the article you're replying to that the standard in
this
case is self-contradictory for quite a different reason, namely, that the
standard elsewhere, in ?9.2/17, defines an additional conversion.
Also, your interpretation disagrees with several other threads in
these forums in recent times.
Don't know about that, but listen to logic and facts.
If those threads got the logic and/or facts wrong, as you indicate, then
really
it's about time that this was set straight.
But are you sure that they got it wrong, or, considering your above
incorrect
interpretation of the standard's text (by ignoring the lead-in part of a
sentence), perhaps you've misunderstood those threads?
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.
Yes.
The allowed general round-trip conversion is contingent on "where the
alignment
requirements of T2 are no stricter than those of T1".
I didn't discuss that, but if we're going to be very precise it needs to be
stated. :-)
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.
See above, there's no conflict.
And the standard is not schizophrenic in that regard.
The inconsistency of ?5.2.10/7 is instead with the defined case of ?9.2/17.
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;
}
It has that as a consequence and I believe basic motivation, yes, treating
an
initial part of a POD struct X where that part is layout-compatible with Y,
as a Y.
However, while the standard in ?9.2./16 does ensure layout compatibility for
the
common identically declared initial part of two POD structs, for in-practice
C++
programming such C-like redundancy is Evil(TM), for even when the programmer
manages to get it right initially it can easily lead to the two definitions
diverging through maintainance of the code -- including not only changes
to
the declarations themselves but e.g. packing pragmas.
And so for the in-practice the basic example is more like
struct T { int x; };
struct U { T basePart; int z; };
not merely repeating declarations of the same elements.
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.
Well, you misunderstood the standard's text about "unspecified", by ignoring
the
"except" earlier in the sentence.
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.
Nope, see above.
[snip]
(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*.
Uh huh, I forgot to qualify this with alignment considerations.
I *apologize* for that omission, but then, I'm purportedly human... ;-)
So, add "suitably aligned" (or more precise language such as "with suitably
aligned referents" or even more precise language such as the standard's, but
if
we start repeating the standard's exact language then nothing is gained).
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.
Well, sorry, no, it talks about the storage for an object before or after
the
object's lifetime.
Again, context is important.
But I agree that there is an implication and assumption here and elsewhere
about
char*. Conversion to char* is practically well-defined for PODs. But
although
that is necessary to know to make sense of ?3.8/5 it isn't specified by
?3.8/5;
it stems, AFAIK, only from the general ?9.2/17 (however, given how the
standard
is, it wouldn't necessarily be a surprise if it's also present somewhere
else).
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.
It's the same assumption, where to make sense of it you need to keep ?9.2/17
in
sight.
3.10/15, the strict aliasing rule, also strongly suggests being able
to access any object through a char* or unsigned char*.
I think you'll agree that it's trivial to construct a case of UB using one
of
the ways of referring to an object listed in the $3.10/15 paragraph.
So again it's ?9.2/17 that you need to make sense of it. $3.10/15 doesn't
talk
about what's allowed. It talks about cases that are definitely UB by
explicitly
listing all the cases that are /not always/ UB, noting that conversion to
e.g.
char* is not necessarily always UB. "if ... other ... the behavior is
undefined"
does not mean that "if [one of these] the behavior is defined". It means
what it
says, that if you refer to an object in any other way then you're guaranteed
UB,
while if you constrain yourself to the listed ways, you may or may not have
UB.
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.
Uhm, I'm not sure what you're arguing /for/, or against.
But apart from that possible implication I agree with the above paragraph.
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.
Right.
Thus round-trip pointer casts not going
through void*, char*, or unsigned char* are undefined (or at best
unspecified) behavior.
I'm sorry, that's incorrect. See above. All that the standard requires for
well-defined'ness of roundtrip conversion, as discussed and quoted above, is
suitable alignment of referents.
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).
I think that's a very dangerous idea. Reportedly Andrei and Herb put forth
this
idea in their C++ coding guidelines book. But until I've seen some rationale
(reportedly they forgot to include any rationale) I regard it as extremely
dangerous, with no benefits and many severe problems, for by introducing
void*
as an intermediary all local type information is lost, and one ends up
passing
void* pointers around, which exacerbates that problem. It also, but less
importantly, is in direct conflict with writing what you mean. When you use
the
double static_cast others will have to spend time on figuring out why you're
doing that, only, in the best case, discovering that it's due only to some
misguided idea that *waiving frenetically* it's less unsafe or whatever.
Cheers & hth.,
- Alf
--
Due to hosting requirements I need visits to <url:
http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]