Error when casting an integer to a pointer to an integer

Quote:

warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
pi = (int *)num;

num is an integer:

int num = 10;

Which means in your compiler that it is probably a 32 bit number - it can hold values between −2,147,483,648 (−2³¹) through 2,147,483,647 (2³¹ − 1) )
pi is a pointer to an integer, which on your compiler means it's a 64 bit pointer.

int *pi = #

(And yes, to compile your app you do need to terminate that line with a semicolon)

int *pi = &num

While it's possible to cast an integer to a pointer, it's not a good idea, partly because you can't get a valid 64 bit pointer into 32 bits, and partly because it's possible to cause strange errors.
When the processor fetches a 64 bit number, it ignores the lowest 4 bits of the address, because 64 bit memory accesses always occur on 16 byte boundaries: Data Alignment when Migrating to 64-Bit Intel® Architecture[^]
32 bit values are aligned to 8 byte addresses, so as far as treating it as a 64 bit pointer it could access your integer value at the top or bottom 32 bits of the pointer.

This means that you could make a seemingly innocent and innocuous change to your app, and an unrelated piece of code fails in strange ways.
So when you try to cast the integer to a pointer, the compiler says "Are you sure you know what you are doing? Do you really want to do that?":

pi = (int *)num;

And the answer is "No! I made a mistake!"And you actually wanted this:

pi = #

int num;
...
(int *)num;

Never.
Do.
This!

OriginalGriff already pointed out why this will go wrong (most of the time). I'm going a step further - here are some general concerns:

1. When you need to cast the type of something to something else, this is very often a sign that something is wrong in your code to start with: either you chose an inappropriate type for your local variable, or you are not using your variables correctly. Or maybe something else. Well written code typically doesn't need a type cast. A type cast in C/C++ code is like saying you "made the kessel run in less than 12 parsecs"[^] : you're not using the right unit of measurement!

2. Never cast a pointer type to a non-pointer type or vice versa. An address is something entirely different than the object situated at that address. There's just one exception I can think of, only that it's caused by Microsoft and therefore cannot be avoided: the use of DWORD to pass pointers/addresses via Windows events. Microsoft changed their ancient win32 libraries to use the type DWORD_PTR instead. Not much of an improvement, but at least this will use a sufficiently large int type to hold the pointer and work as expected. Still no excuse to use that pattern for your own code.

3. In C++ (your question is tagged as C++) you should not use C-style type casts. Instead you should use reinterpret_cast, dynamic_cast, static_cast, or const_cast (see Type conversions - C++ Tutorials[^]

4. When you write some_type variable; and then (some_other_type)variable you are telling the compiler to completely ignore the original declaration of your variable. The compiler will check how much space some_other_type requires, and access the memory at the address of your variable using the size of some_other_type. If the type sizes don't match, this will likely cause serious problems. Even if they do match, that is no guarantee that the following code will treat your variable correctly. Fortunately, if you use C++ type conversions (see item 3 above), then the compiler will warn you about potential issues of this kind. If you use C-style type casts, the compiler will often remain silent, because to the C compiler, a type cast is the equivalent of saying: "shut up, I know better than you". And that kind of assertion is almost always false.

5. C style type casts have the annoying(?) side effect of sometimes doing more than just reinterpreting memory: when you cast one numeric type to another, you'll get a meaningful conversion. E. g. int num = (int)3.14; will yield 3, not some weird number that you'll get by reinterpreting the IEEE representation of the float value 3.14. That behaviour is certainly something you can learn and get used to, but it's just another stone you can trip over when using type casts without need, or inappropriately.