Is it safe to cast an unsigned char* to char*, and treat the dereferenced pointer as if it really points to a char?

Question

Following the question titled Warning generated due wrong strcmp parameter handling, there seems to be some questions regarding what the Standard actually guarantees regardi

Answer 1

THIS MIGHT SURPRISE YOU,

but there's no such guarantee in the C++11 Standard (N3337), nor in the upcoming C++14 (N3797).

char unsigned * p1 = ...;
char          * p2 = reinterpret_cast (p1);

*p1 == *p2; // (1), not guaranteed to be true

^{Note: it is implementation specific whether char is signed or unsigned; [basic.fundamental]p1.}

---

DETAILS

The Standard guarantees that every character type shall;

• have the same alignment requirement;
• occupy the same amount of storage, and;
• that all bits of the storage occupied by a character type shall participate in the value representation, and;
• that the value representation is the same.

Sharing the same amount of storage, alignment requirement, and the guarantee about bit participation, means that casting a lvalue referring to one type (unsigned char), to another (char), is safe.. as far as the actual cast is concerned.

3.9.1p1 Fundamental types [basic.fundamental]

It is implementation-defined whether a char can hold negative values. Characters can be explicitly declared signed or unsigned.

A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (3.11); that is, they have the same object representation. For character types, all bits of the object representation participate in the value representation.

For unsigned character types, all possible bit patterns of the value representation represent numbers. These requirements do not hold for other types.

3.9p4 Types [basic.types]

The object representation of an object of type T is the sequence of N unsigned char objects taken up by the object of type T, where N equals sizeof(T). The value representation of an object is the set of bits that hold the value of type T.

---

SO, WHAT ARE THE PROBLEM(s)?

If we assign the maximum value of an unsigned char (UCHAR_MAX) to *p1 and *p2 is signed, *p2 won't be able to represent this value. We will overflow *p2 and it will, most likely, end up having the value of -1.

^{Note: signed integer overflow is actually undefined behavior.}

---

*p1 = UCHAR_MAX;

*p1 == *p2; // (1)

---

Both sides of operator== must have the same type before we can compare them, and currently one side is unsigned char and the other char.

The compiler will therefor resort to integral promotion to find a type that can represent all combined possible values of the two types; and in this case the resulting type will be int.

After the integral promotion the statement is semantically equivalent to int (UCHAR_MAX) == int(-1), which of course is false.