When and how is conversion to char pointer allowed?

Question

We can look at the representation of an object of type T by converting a T* that points at that object into a char*. At least in practice:

int x = 511;
unsigned char* cp = (unsigned char*)&x;
std::cout << std::hex << std::setfill('0');
for (int i = 0; i < sizeof(int); i++) {
  std::cout << std::setw(2) << (int)cp[i] << ' ';
}

This outputs the representation of 511 on my system: ff 01 00 00.

There is (surely) some implementation defined behaviour occurring here. Which of the casts is allowing me to convert an int* to an unsigned char* and which conversions does that cast entail? Am I invoking undefined behaviour as soon as I cast? Can I cast any T* type like this? What can I rely on when doing this?

I don't think it's undefined behavior, at least if you don't modify the data. But the result will depend on whether you platform is little or big endian. — Synxis, Dec 21 '12 at 19:10
Note that this is only safe for `char *`. Casting pointers to make them read as different types causes problems with *aliasing*. The C and C++ languages guarantee to the compiler that pointers to different types can never point to the same object so the optimizer can do things like store the value in a register or hoist a load or write out of a loop. `char *` is the only exception. A `char *` has to be assumed to alias with anything, because of serialization to and from disk and network buffers. — Zan Lynx, Dec 21 '12 at 19:26
@ZanLynx - Re "`char*` is the only exception": Not quite. The standard also allows conversion to `unsigned char*`. — David Hammen, Dec 21 '12 at 19:33
Also see [What is the strict aliasing rule](https://stackoverflow.com/a/51228315/1708801) — Shafik Yaghmour, Jul 17 '18 at 05:26

score 19 · Accepted Answer · answered Dec 21 '12 at 19:26

Which of the casts is allowing me to convert an int* to an unsigned char*?

That C-style cast in this case is the same as reinterpret_cast<unsigned char*>.

Can I cast any T* type like this?

Yes and no. The yes part: You can safely cast any pointer type to a char* or unsigned char* (with the appropriate const and/or volatile qualifiers). The result is implementation-defined, but it is legal.

The no part: The standard explicitly allows char* and unsigned char* as the target type. However, you cannot (for example) safely cast a double* to an int*. Do this and you've crossed the boundary from implementation-defined behavior to undefined behavior. It violates the strict aliasing rule.

Aha, so it looks like (from @GeneBushuyev's and @nobar's answers) the cast from `T*` to any `U*` has unspecified result (but would be fine if I cast back again) and if I were to cast to anything but a `char*` or `unsigned char*` and then *access* the object though that pointer, I would have undefined behaviour (as per strict aliasing). The perfect answer would have both of these points. ;) — Joseph Mansfield, Dec 21 '12 at 19:35

Brent Bradburn · Answer 2 · 2012-12-21T19:34:36.710

8

Your cast maps to:

unsigned char* cp = reinterpret_cast<unsigned char*>(&x);

The underlying representation of an int is implementation defined, and viewing it as characters allows you to examine that. In your case, it is 32-bit little endian.

There is nothing special here -- this method of examining the internal representation is valid for any data type.

C++03 5.2.10.7: A pointer to an object can be explicitly converted to a pointer to an object of different type. 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.

This suggests that the cast results in unspecified behavior. But pragmatically speaking, casting from any pointer type to char* will always allow you to examine (and modify) the internal representation of the referenced object.

edited Dec 21 '12 at 19:34

answered Dec 21 '12 at 19:18

Brent Bradburn

51,587
17
154
173

Strictly speaking, though, the standard does not guarantee that a `char` is smaller than an `int`. – Brent Bradburn Dec 21 '12 at 19:37
2

The relevant standards for the "strict aliasing rule" are provided here: http://stackoverflow.com/a/7005988/86967. Synopsis: If you access the object via `char*` or `unsigned char*`, there is no problem. – Brent Bradburn Dec 21 '12 at 19:50
This is highly tangential, but it is interesting to note that the _strict aliasing rule_ suggests that the use of a `char*` can interfere with optimization. This is where the [non-standard](http://stackoverflow.com/questions/6434549/does-c11-add-the-c99-restrict-specifier-if-not-why-not) `restrict` keyword can be useful -- although it doesn't apply to the question at hand, since _aliasing_ is exactly the point of the given question. – Brent Bradburn Dec 21 '12 at 20:25
Related/of interest: [Do the strict aliasing rules in C++20 allow `reinterpret_cast` between the standard c++ unicode chars and the underlining types?](https://stackoverflow.com/q/56415276/86967) – Brent Bradburn Jun 02 '19 at 13:56

score 4 · Answer 3 · answered Dec 21 '12 at 19:26

The C-style cast in this case is equivalent to reinterpret_cast. The Standard describes the semantics in 5.2.10. Specifically, in paragraph 7:

"A pointer to an object can be explicitly converted to a pointer to a different object type.70 When a prvalue v of type “pointer to T1” is converted to the type “pointer to cvT2”, the result is static_cast<cvT2*>(static_cast<cvvoid*>(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. Converting a prvalue 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 any other such pointer conversion is unspecified."

What it means in your case, the alignment requirements are satisfied, and the result is unspecified.

Ah, so it's only well-defined when you cast from a `T*` to a `U*` and back to a `T*`? The result of a `T*` cast to a `U*` only is unspecified? Aha. — Joseph Mansfield, Dec 21 '12 at 19:28

score 3 · Answer 4 · answered Dec 21 '12 at 19:18

The implementation behaviour in your example is the endianness attribute of your system, in this case your CPU is a little endian.
About the type casting, when you cast an int* to char* all what you are doing is telling the compiler to interpret what cp is pointing to as a char, so it will read the first byte only and interpret it as a character.

score 1 · Answer 5 · answered Dec 21 '12 at 19:19

The cast between pointers are themselves always possible since all pointers are nothing more than memory addresses and whatever type, in memory, can always be thought as a sequence of bytes.

But -of course- the way the sequence is formed depends on how the decomposed type is represented in memory, and that's out of the scope of the C++ specifications.

That said, unless of very pathological cases, you can expect that representation to be the same on all the code produced by a same compiler for all the machines of a same platform (or family), and you should not expect same results on different platforms.

In general one thing to avoid is to express the relation between type sizes as "predefined": in your sample you assume sizeof(int) == 4*sizeof(char): that's not necessarily always true.

But it is always true that sizeof(T) = N*sizeof(char), hence whatever T can always be seen as a integer number of char-s

I'm missing where the OP assumed that `sizeof(int) == 4*sizeof(char)`. — phonetagger, Dec 21 '12 at 19:24
@phonetagger Emilio may have been answering the original version of my question which did rely on it being `4*sizeof(char)`. — Joseph Mansfield, Dec 21 '12 at 19:39
@sftrabbit - Fine. But delete your comment saying "No need to delete..." — phonetagger, Dec 21 '12 at 20:20

score 0 · Answer 6 · answered Dec 21 '12 at 19:22

Unless you have a cast operator, then a cast is simply telling to "see" that memory area in a different way. Nothing really fancy, I would say.

Then, you are reading the memory area byte-by-byte; as long as you do not change it, it is just fine. Of course, the result of what you see depends a lot from the platform: think about endianness, word size, padding, and so on.

score 0 · Answer 7 · answered Dec 21 '12 at 19:26

0

Just reverse the byte order then it becomes

00 00 01 ff

Which is 256 (01) + 255 (ff) = 511

This is because your platfom is little endian.

answered Dec 21 '12 at 19:26

lanoxx

12,249
13
87
142

When and how is conversion to char pointer allowed?

7 Answers7

Linked