Are there cases where casting a long to pointer is valid

Question

In my C++ learning process I've come across code like this in x86 which I don't understand:

unsigned long value = 50;
unsigned char* result = (unsigned char*)value;

Inspecting the pointer gives a memory access error (i.e. I can't write std::cout << *result;). If anything the cast line should be like:

unsigned char* result = (unsigned char*)&value;

But it isn't. So my question is, under what circumstances (if any) is the first cast usable? Or put in another way, is it possible to get the data from the pointer?

Answer 1

I am currently working on some digital signal processing, which involves programming an Analog Devices DSP. Here is a small snippet from one of the .h files that they ship with the board:

#define pUART0THR                ((volatile unsigned int *)0x3c00)    /* Transmit Holding Register */
#define pUART0RBR                ((volatile unsigned int *)0x3c00)    /* Receive Buffer Register */
#define pUART0DLL                ((volatile unsigned int *)0x3c00)    /* Divisor Latch Low Byte */
#define pUART0IER                ((volatile unsigned int *)0x3c01)    /* Interrupt Enable Register */

I bet you would be able to find similar stuff if you dive into the headers for just about any other embedded system.

In this case 0x3c00 is a memory address that you can write a byte to, and have a hardware UART module read it and transmit it over the serial port. And 0x3c01 is the address of a register, where if you set the second bit (bit 1), then you will get a hardware interrupt when the UART send buffer (at address 0x3c00) is empty = the byte you put there has been send.

However, so that you don't have to remember all these addresses, and get some nice (or at least more memorable) names to call them by, they have a bunch of defines like the ones above.

Answer 2

There are some cases, but often it is not appropriate.

The conversion is valid only if:

• long is sufficiently large type to represent all addresses. This is not guaranteed. In fact, long is not sufficiently large on 64 bit Windows systems. There is an integer type that is guaranteed to be correctly sized for this purpose: std::uintptr_t.

---

Of course, this conversion is completely pointless unless you intend to do something with the pointer. Whether those things are valid depend on yet more requirements.

• If the converted pointer value is invalid i.e. does not refer to an allocated area of storage, then indirecting through the pointer has undefined behaviour. Any other use (such as comparing the value to another pointer) has implementation defined behaviour.
• If the pointer is to an object outside of its lifetime, but with allocated storage, then the pointer can only be used in limited way. Accessing memory through the pointer is still typically (exceptions apply) undefined behaviour, but you can for example compare the values equality with another valid pointer. Refer to standard sections [basic.life], [class.base.init] and [class.cdtor] for details on what is allowed.
• If the pointer is to an object within its lifetime, and the pointer is of same type (or compatible type), then you can indirect through the pointer to access the pointed object.

Note that the mapping of the conversion from integer to pointer is implementation defined. Pretty much only guarantee you have is that a pointer that is converted into an integer of sufficient size can be converted back to the same value.

---

The above describes only when the conversion and use of the converted pointer is valid. Another matter is whether there is any point in doing this. The use cases are rare on desktop / server systems (see andrey's answer for an example), but on embedded systems, there are sometimes hard coded addresses for communicating with the hardware (see Frodyne's answer for an example).

Answer 3

One potential reason to cast an integer to a pointer would be to transport that integer value through an API that accepts a pointer.

For example, many callback-related APIs accept a void *user_data parameter to be passed as an argument to the callback function. Consider the following function:

void do_async_thing(args..., void (* callback) (int result, void *user_data), void *user_data);

If all you need to pass to the callback is an integer, then instead of passing a pointer to an allocated block of data, you might write:

do_async_thing(
    args...,
    [](int result, void *request_idx) {
        std::cout << "request " << reinterpret_cast<std::uintptr_t>(request_idx) << " returned " << result;
    },
    reinterpret_cast<void *>(std::uintptr_t{request_idx})
);

Of course you should use std::uintptr_t, not unsigned long (e.g. on Windows unsigned long is 32 bits).

---

Another reason would be if on your specific platform you happen to know that there is a valid object at that address (e.g. on some embedded device).

Ultimately this is all implementation-defined. std::uintptr_t may not even exist on a specific platform.

Answer 4

unsigned long value = 50;
unsigned char* result = (unsigned char*)value;  

now the pointer result contains the number 50, in other words it points to the address 50. But on modern platforms you cannot simply address any memory address.

Therefore this code will result in undefined behaviour (usually a crash).

std::cout << *result;