Is reinterpret_cast mostly useless?

Question

I've read various previous questions about the use of reinterpret_cast, and I've also read the relevant wording in the C++ standard. Essentially, what it comes down to is that the result of a pointer-to-pointer reinterpret_cast operation can't safely be used for anything other than being cast back to the original pointer type.

In practice, however, most real-world uses of reinterpret_cast seem to be based on the (wrong) assumption that a reinterpret_cast is the same as a C-style cast. For example, I've seen lots of code which uses reinterpret_cast to cast from char* to unsigned char* for the purpose of character set conversion routines. This is completely harmless, yet strictly speaking it's not portable - there's no guarantee that a reinterpret_cast from char* to unsigned char* won't crash your program when you try to dereference the unsigned char* pointer.

It's seems the only other real use of reinterpret_cast that has any real guarantees, according to the standard, is converting from pointer to integer, and vice-versa.

And yet there are many cases where we'd want (and should be able to) safely convert between different pointer types. For example: uint16_t* to the new C++0x char16_t*, or really any pointer to a basic data type that is the same size/alignment as the original type. Yet reinterpret_cast provides no guarantees this should work.

Question: How can we safely convert between pointers to basic data-types of the same size/alignment, such as char* --> unsigned char*? Since reinterpret_cast doesn't seem to guarantee this actually works, are C-style casts the only safe option here?

Answer 1

there's no guarantee that a reinterpret_cast from char* to unsigned char* won't crash your program when you try to dereference the unsigned char* pointer.

You can't do such a cast in any other way, so you have to have to trust what your compiler does with this completely reasonable cast.

Since reinterpret_cast doesn't seem to guarantee this actually works, are C-style casts the only safe option here?

The C-style cast will just map to reinterpret_cast so it will be exactly the same. At some point you have to trust your compiler. The Standard has a limit on which it simply says "no. read your compiler's manual". When it comes to cross-casting pointers, this is such a point. It allows you to read a char using an unsigned char lvalue. A compiler that cannot cast a char* to a usable unsigned char* to do such is just about unusable and doesn't exist for that reason.

Answer 2

the result of a pointer-to-pointer reinterpret_cast operation can't safely be used for anything other than being cast back to the original pointer type.

That does not sound right. Assuming sizeof(void *) > sizeof(int *), void *foo; reinterpret_cast<void *>(reinterpret_cast<int *>(foo)) could leave you with a truncated pointer value.

Is it not that reinterpret_cast is — in practice — simply the equivalent to C's default cast?

Answer 3

The standard specifies what has to happen on all platforms, you don't have to do that. If you limit your portability requirements to platforms where your reinterpret_cast actually works, that's fine.

On platforms that actually support a uint16_t, the cast is likely to work. On platforms where char16_t is 18, 24, 32, or 36 bits wide, it might not do the right thing. The question is, do you have to support such platforms? The language standard wants to.

Answer 4

There are some guarantees elsewhere in the standard (see the section on type representation which, IIRC, mandates that corresponding unsigned and signed types share the representation for the common values, still IIRC, there is also some text guaranteeing that you can read anything as characters). But note also that there are some places which lessen even the section you are reading (which states that things are implementation defined and unspecified): some forms of type punning are undefined behavior.

Answer 5

Essentially, what it comes down to is that the result of a pointer-to-pointer reinterpret_cast operation can't safely be used for anything other than being cast back to the original pointer type.

You are right, the standard was broken, but N3242 tries to fix that:

Definition of the value of reinterpret_cast<T*>

N3242, [expr.reinterpret.cast]:

When a prvalue v of type “pointer to T1” is converted to the type “pointer to cv T2”, the result is static_cast<cv T2*>(static_cast<cv void*>(v)) if both T1 and T2 are standard-layout types (3.9) and the alignment requirements of T2 are no stricter than those of T1.

This still defines nothing; for fun, the less irrelevant text about static_cast:

A prvalue of type “pointer to cv1 void” can be converted to a prvalue of type “pointer to cv2 T,” where T is an object type and cv2 is the same cv-qualification as, or greater cv-qualification than, cv1. The null pointer value is converted to the null pointer value of the destination type. A value of type pointer to object converted to “pointer to cv void” and back, possibly with different cv-qualification, shall have its original value.

"Suitably converted"

N3242, [class.mem]:

A pointer to a standard-layout struct object, suitably converted using a reinterpret_cast, points to its initial member (or if that member is a bit-field, then to the unit in which it resides) and vice versa.

What kind of style is that? "suitably"? lol

Clearly, these guys don't know how to write a specification.

C-style casts the only safe option here?

It doesn't help.

The standard is broken, broken, broken.

But everybody understands what it really means. The subtext of the standard says:

When a prvalue v of type “pointer to T1” is converted to the type “pointer to cv T2”, the result is static_cast<cv T2*>(static_cast<cv void*>(v))points to the memory address as v if both T1 and T2 are standard-layout types (3.9) and the alignment requirements of T2 are no stricter than those of T1.

That's certainly not perfect (but not worse than many others parts of the standard), but in 2 mn I wrote a better spec than the committee did in a decade.