Here is a code -
1 int main(int argc, char *argv[])
2 {
3 signed char S, *psc;
4 unsigned char U, *pusc;
5 char C, *pc;
6
7 C = S;
8 C = U;
9
10 pc = psc;
11 pc = pusc;
12
13 return 0;
14 }
$ gcc test.cpp -o a
test.cpp: In function ‘int main(int, char**)’:
test.cpp:10:7: error: invalid conversion from ‘signed char*’ to ‘char*’ [-fpermissive]
test.cpp:11:7: error: invalid conversion from ‘unsigned char*’ to ‘char*’ [-fpermissive]
This is compiled on gcc version 4.6.3 on Ubuntu 12.10 on an Intel 32-bit machine.
Considering that char type is unsigned char on x86. -
If assignments on line 7 and 8 for non-pointer types are Ok, why errors are thrown for pointer types on lines 10 and 11 ?
Also, should C = U succeeds without requiring a cast?
First of all, it is important to stress the fact that char, signed char, and unsigned char are all different types. Section 4.10 of the C++11 Standard defines the three possible standard pointer conversions between pointers of different types:
1 . A null pointer constant is an integral constant expression (5.19) prvalue of integer type that evaluates to zero or a prvalue of type std::nullptr_t. A null pointer constant can be converted to a pointer type; the result is the null pointer value of that type and is distinguishable from every other value of object pointer or function pointer type. Such a conversion is called a null pointer conversion. Two null pointer values of the same type shall compare equal. The conversion of a null pointer constant to a pointer to cv-qualified type is a single conversion, and not the sequence of a pointer conversion followed by a qualification conversion (4.4). A null pointer constant of integral type can be converted to a prvalue of type std::nullptr_t. [ Note: The resulting prvalue is not a null pointer value. —end note ]
This is not relevant, since we don't have null pointers of type nulltptr_t here.
2 . A prvalue of type “pointer to cv T,” where T is an object type, can be converted to a prvalue of type “pointer to cv void”. The result of converting a “pointer to cv T” to a “pointer to cv void” points to the start of the storage location where the object of type T resides, as if the object is a most derived object (1.8) of type T (that is, not a base class subobject). The null pointer value is converted to the null pointer value of the
destination type.
This cannot apply, since the destination type is not void. Finally,
3 . A prvalue of type “pointer to cv D”, where D is a class type, can be converted to a prvalue of type “pointer to cv B”, where B is a base class (Clause 10) of D. If B is an inaccessible (Clause 11) or ambiguous (10.2) base class of D, a program that necessitates this conversion is ill-formed. The result of the conversion is a pointer to the base class subobject of the derived class object. The null pointer value is converted to the
null pointer value of the destination type.
signed char is not a base class of char, so not even this applies.
Therefore, an implicit, standard pointer conversion from signed char to char cannot be performed.
On the other hand, conversions between values of integral types are permitted according to what specified in Paragraph 4.7.
C++ don't have automatic pointer conversion, it does not matter what are the pointer types on each side of the assignment, if they are different, you need a cast.
char is a distinct type from unsigned char and signed char. It is only guaranteed to have equivalent value representation to one of them, but it is still a distinct type. You therefore cannot convert from either unsigned char* or signed char* to char* (that is, unless you use a reinterpret_cast). C++ just doesn't allow pointer conversions between distinct types like this, because then one type could masquerade as another.
However, a conversion from either unsigned char or signed char to char is perfectly fine because it just involves a conversion of its value.
Consider it this way: you can convert an int to a float, but you can't convert an int* to a float*.
I could be wrong, but as said above, when you assigned "C = S; C = U;", C++ automatically converts it, kinda like if you do "char x = "h"; printf("%i", x);". However, pointers point to a specific location in memory, and that location has a size. So while converting sort of just looks at the values from a different angles, pointing to different values may involve changing the size of the value that is being pointed at.
Related
I was looking at https://en.cppreference.com/w/cpp/language/reinterpret_cast and I noticed that it specifies the legal types we can always cast to:
byte*
char*
unsigned char*
But I did not see void* in the list. Is this an oversight? My use case requires a reinterpret_cast because I'm casting from an int** to a void*. And I will eventually cast from the void* back to an int**.
Those types are exempt from strict aliasing rules. It does not mean they are the only type you can use with reinterpret_cast. In the case of casting an object pointer to another object pointer type, failing to meet the requirements of strict aliasing rules means you cannot safely dereference the result. But you can still cast the resulting pointer back to the original type safely, and use the result as-if it was the original pointer.
The relevant section from cppreference on reinterpret_cast :
(Any object pointer type T1* can be converted to another object pointer type cv T2*. This is exactly equivalent to static_cast<cv T2*>(static_cast<cv void*>(expression)) (which implies that if T2's alignment requirement is not stricter than T1's, the value of the pointer does not change and conversion of the resulting pointer back to its original type yields the original value). In any case, the resulting pointer may only be dereferenced safely if allowed by the type aliasing rules)
When casting back to the original type, AliasedType and DynamicType are the same, so they are similar, which is the first case listed by the aliasing rules where it is legal to dereference the result of reinterpret_cast :
Whenever an attempt is made to read or modify the stored value of an object of type DynamicType through a glvalue of type AliasedType, the behavior is undefined unless one of the following is true:
AliasedType and DynamicType are similar.
AliasedType is the (possibly cv-qualified) signed or unsigned variant of DynamicType.
AliasedType is std::byte, (since C++17)char, or unsigned char: this permits examination of the object representation of any object as an array of bytes.
[expr.reinterpret.cast]/7:
An object pointer can be explicitly converted to an object pointer of a different type.
[basic.compound]/3:
The type of a pointer to cv void or a pointer to an object type is called an object pointer type.
You don't need to use reinterpret_cast, though. Every object pointer type whose pointed type is cv-unqualified is implicitly convertible to void*, and the inverse can be done by static_cast.
It is always legal to convert from a pointer to a type to a pointer to a different type including void, so if T is a type this is legal C++:
T* x;
void *y = reinterpret_cast<void *>(x);
In real world it is never used because void * is a special case, and you obtain the same value with static_cast:
void *y = static_cast<void *>(x); // equivalent to previous reinterpret_cast
(in fact above conversion is implicit and can be simply written void *y = x; - thank to Michael Kenzel for noticing it)
To be more explicit the standard even says in draft n4659 for C++17 8.2.10 Reinterpret cast [expr.reinterpret.cast], §7
When a prvalue v of
object pointer type is converted to the object pointer type “pointer to cv T”, the result is static_cast<cv T*>(static_cast<cv void*>(v)).
When you refer to byte and char being the only legal types, it is just that it is legal to dereference the converted pointer only for those types. void is not included here because you can never dereference a void *.
To specifically answer your question
.. I'm casting from an int** to a void*. And I will eventually cast from the void* back to an int**.
The standard guarantees that first one is a standard (read implicit) conversion:
A prvalue of type “pointer to cv T”, where T is an object type, can be converted to a prvalue of type “pointer
to cv void”. The pointer value (6.9.2) is unchanged by this conversion.
So this is always legal:
int **i = ...;
void *v = i;
For back casting, standard says (in static_cast paragraph):
A prvalue of type “pointer to cv1 void” can be converted to a prvalue of type “pointer to cv2 T”,
So this is also legal
int **j = static_cast<int **>(v);
and the standard ensures that j == i.
After reading about the standard C11 version of Martin Uecker's ICE_P predicate, I tried to implement it in pure C++. The C11 version, making use of _Generic selection is as follows:
#define ICE_P(x) _Generic((1? (void *) ((x)*0) : (int *) 0), int*: 1, void*: 0)
The obvious approach for C++ is to replace _Generic by a template and decltype, such as:
template<typename T> struct is_ice_helper;
template<> struct is_ice_helper<void*> { enum { value = false }; };
template<> struct is_ice_helper<int*> { enum { value = true }; };
#define ICE_P(x) (is_ice_helper<decltype(1? (void *) ((x)*0) : (int *) 0)>::value)
However, it fails the simplest test. Why can't it detect integer constant expressions?
The issue is subtle. The specification for determining the composite type of the conditional expression's pointer operands are similar in C++ to the ones in C, so it starts off looking promising:
(N4659) [expr.cond]
7 Lvalue-to-rvalue, array-to-pointer, and function-to-pointer
standard conversions are performed on the second and third operands.
After those conversions, one of the following shall hold:
[...]
One or both of the second and third operands have pointer type; pointer conversions, function pointer conversions, and qualification
conversions are performed to bring them to their composite pointer
type (Clause [expr]). The result is of the composite pointer type.
[...]
The reduction to the composite pointer type is specified as follows:
(N4659) [expr]
5 The composite pointer type of two operands p1 and p2 having
types T1 and T2, respectively, where at least one is a pointer or
pointer to member type or std::nullptr_t, is:
if both p1 and p2 are null pointer constants, std::nullptr_t;
if either p1 or p2 is a null pointer constant, T2 or T1, respectively;
if T1 or T2 is “pointer to cv1 void” and the other type is “pointer to cv2 T”, where T is an object type or void, “pointer to cv12 void”,
where cv12 is the union of cv1 and cv2;
[...]
So the result of our ICE_P macro is determined by which of the bullets above we land one after checking each in order. Given how we defined is_ice_helper, we know that the composite type is not nullptr_t, otherwise we'd hit the first bullet, and will get an error due to the missing template specialization. So we must be hitting bullet number 3, making the predicate report false. It all seems to hinge on the definition of a null pointer constant.
(N4659) [conv.ptr] (emphasis mine)
1 A null pointer constant is an integer literal with value
zero or a prvalue of type std::nullptr_t. A null pointer
constant can be converted to a pointer type; the result is the null
pointer value of that type and is distinguishable from every other
value of object pointer or function pointer type. Such a conversion is
called a null pointer conversion. Two null pointer values of the same
type shall compare equal. The conversion of a null pointer constant to
a pointer to cv-qualified type is a single conversion, and not the
sequence of a pointer conversion followed by a qualification
conversion. A null pointer constant of integral type can be converted
to a prvalue of type std::nullptr_t.
Since (int*)0 is not a null pointer constant by the definition above, we do not qualify for the first bullet of [expr]/5. The composite type is not std::nullptr_t. Neither is (void *) ((x)*0) a null pointer constant, nor can it be turned into one. Removing the cast (something the definition doesn't allow) leaves us with (x)*0. This is a integer constant expression with value zero. But it is not an integer literal with value zero! The definition of a null pointer constant in C++ deviates from the one in C!
(N1570) 6.3.2.3 Pointers
3 An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant. If
a null pointer constant is converted to a pointer type, the resulting
pointer, called a null pointer, is guaranteed to compare unequal to a
pointer to any object or function.
C allows arbitrary constant expressions with value zero to form a null pointer constant, while C++ requires integer literals. Given C++'s rich support for computing constant expressions of a variety of literal types, this seems like a needless restriction. And one that makes the above approach to ICE_P a non-starter in C++.
I want to cast a pointer pc which points to char to a point pi which points to int
char *pc;
int *pi;
pi = (int*)pc // compiler complaint about old-style cast
pi = static_cast<int *>(static_cast<void *>(pc)) // no complaint any more but too complex
is there any simpler ways to do this cast and make compiler silence?
If you really need to do this then reinterpret_cast is your friend:
char *pc = 0;
int *pi = 0;
pi = reinterpret_cast<int*>(pc);
The behaviour on converting, in general, a char* pointer to an int* pointer is undefined. Dereferencing such a pointer will cause you further trouble as you will be breaking strict aliasing rules. Note that the C++ Standard does not require sizeof(char*) to be the same as sizeof(int*).
(Note that converting an unsigned char* pointer to an int* is well-defined if the unsigned char* pointer actually points to an int).
Don't do it. Ever.
I want to put the back and forth under #Bathsheba's post to rest. So here's an answer about the finer details of what you are doing.
#Sean already suggested you reinterpret_cast your pointers instead. And that is equivalent to your second chain of casts. It says as much in [expr.reinterpret.cast]/7:
An object pointer can be explicitly converted to an object pointer of
a different type. When a prvalue v of object pointer type is
converted to the object pointer type “pointer to cv T”, the result is
static_cast<cv T*>(static_cast<cv void*>(v)). [ Note: 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. — end note ]
Now, let's examine each step of the two step conversion. First we have a static_cast<void*>. According to [conv.ptr]/2 (emphasis mine):
A prvalue of type “pointer to cv T”, where T is an object type, can be
converted to a prvalue of type “pointer to cv void”. The pointer value
is unchanged by this conversion.
The first conversion doesn't do any alteration to the address. And then it also says in [basic.compound]/5:
A pointer to cv-qualified or cv-unqualified void can be used to point
to objects of unknown type. Such a pointer shall be able to hold any
object pointer. An object of type cv void* shall have the same
representation and alignment requirements as cv char*.
So a char* may store any address a void* may store. Now it doesn't mean the conversion from void* to char* is value preserving, only that they can represent the same values. Now, assuming a very restricted use case, that is enough of a guarantee. But there's more at [expr.static.cast]/13:
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. If
the original pointer value represents the address A of a byte in
memory and A does not satisfy the alignment requirement of T, then the
resulting pointer value is unspecified. Otherwise, if the original
pointer value points to an object a, and there is an object b of type
T (ignoring cv-qualification) that is pointer-interconvertible with a,
the result is a pointer to b. Otherwise, the pointer value is
unchanged by the conversion.
Where am I going with this? Assuming pc already holds the address of an int (suitably converted according to the above), then casting the char* to an int* via reinterpret_cast will give you the address of the original int. The note under the first paragraph says as much, and the further quotes prove it. If it doesn't hold the address of an int, you are playing roulette and are likely going to lose. Your program has undefined behavior. You should follow Bathsheba's advice to the letter.
As I understand, std::nullptr_t can be initialized from nullptr as well as from 0. But at the same time the third initialization below doesn't work, despite 5 has the same type as 0:
#include <memory>
int main()
{
std::nullptr_t null1=0;
std::nullptr_t null2=nullptr;
std::nullptr_t null3=5; // error: cannot convert ‘int’ to ‘std::nullptr_t’ in initialization
}
How does this work? I.e. how does the standard library distinguish 0 from 5 at compilation time, if these literals aren't template arguments?
Can one create a custom class which would similarly distinguish arguments of its constructor at compilation time, not using std::nullptr_t for this?
A nullptr_t can be only assigned the value nullptr or 0 which is implicitly converted.
According to N4296 (page.86):
4.10 Pointer conversions
A null pointer constant is an integer literal with value zero
or a prvalue of type std::nullptr_t. A null pointer constant can be
converted to a pointer type; the result is the null pointer value of
that type and is distinguishable from every other value of object
pointer or function pointer type. [...] A null pointer constant of
integral type can be converted to a prvalue of type std::nullptr_t.
You can not create a similar type within C++ yourself.
std::nullptr_t is implemented as a built-in type and its distinct properties are enforced by the compiler.
EDIT: Fixed paragraph on built-in types. Thanks Yakk!
how does the standard library distinguish 0 from 5 at compilation time, if these literals aren't template arguments?
This has nothing to do with the standard library at all, nullptr_t is a built-in type known to the compiler, and obviously the compiler knows the difference between 5 and 0
Can one create a custom class which would similarly distinguish arguments of its constructor at compilation time, not using std::nullptr_t for this?
In general no.
You can write a type that can be initialized from 0 and not from 5 by making it take an argument of a pointer type, because 0 is a valid null pointer constant but 5 is not. But you couldn't write a type that can be constructed from 3 and not from 5, or anything else like that.
N3337 [conv.ptr]/1: A null pointer constant is an integral constant expression prvalue of integer type that evaluates to
zero or a prvalue of type std::nullptr_t. A null pointer constant can be converted to a pointer type; the
result is the null pointer value of that type and is distinguishable from every other value of object pointer or
function pointer type. Such a conversion is called a null pointer conversion. Two null pointer values of the
same type shall compare equal. The conversion of a null pointer constant to a pointer to cv-qualified type is
a single conversion, and not the sequence of a pointer conversion followed by a qualification conversion. A null pointer constant of integral type can be converted to a prvalue of type std::nullptr_t.
0 is a null pointer constant of integral type, so it can be converted to a prvalue of type std::nullptr_t. 5 is not a null pointer constant, so it can't be.
Can anyone explain what's happening in the following code?
char cd[1024];
unsigned short int & messageSize =reinterpret_cast<unsigned short int&>(*cd);
does it take the first 2 char of cd by reference and cast it to a 16 bit int?
when I remove the '&', the compiler complains about cannot cast from char to unsigned short int.
unsigned short int messageSize =reinterpret_cast<unsigned short int>(*cd);
The "intuitive" meaning of reinterpret_cast is "take a sequence of bits and treat it as if that sequence of bits has a different type". That is not possible to do for types char and unsigned short, because they have different width.
As for the first case, the intuition is: reinterpret_cast treats lvalue reference as if it was a pointer to the type it refers (and applies mentioned conversion to that pointer).
Formally, the standard says:
4.2 Array-to-pointer conversion [conv.array]
An lvalue or rvalue of type “array of N T” or “array of unknown bound of T” can be converted to a prvalue of type “pointer to T”. The result is a pointer to the first element of the array.
and:
5.3.1 Unary operators [expr.unary.op]
The unary * operator performs indirection: the expression to which it is applied shall be a pointer to an object type, or a pointer to a function type and the result is an lvalue referring to the object or function
to which the expression points. If the type of the expression is “pointer to T”, the type of the result is
“T”.
So, after dereferencing *cd we will get an lvalue of type char (same as if you wrote cd[0]).
5.2.10 Reinterpret cast [expr.reinterpret.cast]
A glvalue expression of type T1 can be cast to the type “reference to T2” if an expression of type “pointer to T1” can be explicitly converted to the type “pointer to T2” using a reinterpret_cast. The result refers to the same object as the source glvalue, but with the specified type. [ Note: That is, for lvalues, a reference cast reinterpret_cast<T&>(x) has the same effect as the conversion *reinterpret_cast<T*>(&x) with the built-in & and * operators (and similarly for reinterpret_cast<T&&>(x)). — end note ] No temporary is created, no copy is made, and constructors (12.1) or conversion functions (12.3) are not called.
That means, you have got something like
*reinterpret_cast<unsigned short *>(&cd[0])
But what is perhaps more important than all the above:
3.10 Lvalues and rvalues [basic.lval]
If a program attempts to access the stored value of an object through
a glvalue of other than one of the following types the behavior is
undefined:
the dynamic type of the object,
a cv-qualified version of the dynamic type of the object,
...
a char or unsigned char type.
That is, binding a "reference to char" to an object of type "unsigned short" is ok. But doing vise-versa (i.e., as in your example) is sort-of-not-ok, because accessing such reference would invoke undefined behavior.
Cast with reference is different from the same cast without reference in one thing - cast without reference creates a new temporary object, while cast with reference changes the type of the already existing object. This matters in many cases, for example, in your case, since you assigning a result to a non-const reference. Non-const references can not be inialized with temporary objects.
On a side note, you know that what you are doing here is a violation on type aliasing rule, and is yields undefeined behaviour?
unsigned short int & messageSize means that messageSize is a variable of type unsigned short int, and the memory area where that variable will be stored shall be given as initializer.
The initializer =reinterpret_cast<unsigned short int&>(*cd) says: take the memory at the location being pointed to by cd, and pretend it contains a unsigned short int.
The result is that if you try to read and write messageSize, then you will try to read and write a unsigned short int in a memory location that contains something else. This causes undefined behaviour.
There are a few situations in which it is OK to pretend a memory location contains an object that it actually doesn't; this is not one of them.
If your compiler is not performing aliasing optimizations then it might appear as if your code "works" for now. However the code is broken.
reinterpret_cast<unsigned short int&>(*cd);
is similar to
*reinterpret_cast<unsigned short int*>(cd);