reinterpret_cast and undefined behaviour

[lcarlier]

Channel

C++Weekly

Topics

reinterpret_cast and undefined behaviour.
What is allowed and not allowed.
i.e. can we cast integer to pointer (e.g. for register access)? any risk doing so?
type aliasing.
Some example demonstrating what can go wrong when wrong type aliasing is done.

Length

5-10 minutes

[lefticus]

Reference to existing episode on this topic: https://youtu.be/L06nbZXD2D0

[lcarlier]

Hi Jason,
Thanks! That explains already a lot!

I was wondering whether there is also undefined behaviour when doing volatile reinterpret cast when accessing HW registers.

i.e.

uintptr_t CONFIG_REG_ADDR = 0x10000000;
uint32_t config_reg_val = *reinterpret_cast<volatile uint32_t*>(CONFIG_REG_ADDR);

Can we conclude that whenever data alignment is guaranteed, then reinterpret_cast won't produce UB?

Note that I've seen that using memcpy in this case gives the same ASM with optimized build but I'm still wondering if all the code I've seen so far is just full of UB or if we were just lucky.

[carlosgalvezp]

@lcarlier In this case you have a integer-to-pointer conversion, which as per the Standard is implementation defined. Most likely all microcontroller toolchains implement this correctly as it's the only way to access memory-mapped devices.

[Dharmesh946]

see also #245 (comment)
links with std::bit_cast, std::start_lifetime_as,...

[Dharmesh946]

Reference to existing episode on this topic: https://youtu.be/L06nbZXD2D0

1- Hi, how is it possible to get guarantees that memcpy is optimized away?
2- After the second memcpy (back to the storage), now S object exists in the storage and subsequent reinterpret_cast would be valid (I don't get how memcpy can create implicit lifetime objects without knowledge of the type, it looks like it's the usage of the destination pointer that determines the existence of objets in this case)?
3- how to use that for non default constructible objects? (I'm thinking about allocating the temporary with std::allocator::allocate and destroying it at the end of the function, but it won't be optimized away: https://godbolt.org/z/6zbTMEPnj)

Regards

[VincentZalzal]

With the latest episode (512) about std::start_lifetime_as, I wonder : what are the remaining legitimate uses of reinterpret_cast? If I parsed cppreference correctly, and ignoring some more obscure uses:

• T* to std::uintptr_t and back
• internal pointer to unrelated opaque handle pointer and back (as it is never dereferenced while it is a handle)
• T* to std::byte* (or char, unsigned char) to see its representation, and back
• accessing a contiguous sequence of signed integers as unsigned integers of the same size (or the other way around). Also works for a single integer, but I would use static_cast for that.
• function pointer to void* and back (for dlsym)

[Dharmesh946]

@VincentZalzal : creating objects inside suitably aligned storage and getting them back:

you have an array of bytes "storage"
you place-new some object of type T there (respecting alignment, see std::align)
you retrieve a pointer to a T through std::launder(reinterpret_cast<T*>(storage+offset)), offset being the offset in byte inside the storage to your object.

to avoid that you can save the result of the placement new to a T* variable.

[VincentZalzal]

@Dharmesh946 You're right! I see this as a special case of point 3 (T* to std::byte* and back), but it is a useful case, especially when implementing containers.

[Dharmesh946]

@VincentZalzal I would say that examining object representation is another matter. It is now bugged in the standard (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p1839r7.html). The best way I found was to use std::bit_cast the object to examine to an array of bytes, hoping for the compiler to recognize the pattern and optimize.
converting pointer from and to integer has no operational value, only for debugging as this conversion is compiler dependent.
I think that the last 2 points are better achieved through static_cast.

[Dharmesh946]

another use-case for reinterpret_cast: with std::construct_at. AFAIU it requires a location as T* so if you want to construct a T on, say, a storage of bytes:

alignas(T) std::byte storage[sizeof(T)];
T* ptr = std::construct_at(reinterpret_cast<T*>(storage),args);

this is legal as the storage address is assumed to be voidified internally (https://stackoverflow.com/a/77233807/21691539)

I hope it will be addressed also there: #509

side note, I'm wondering why the signature of std::construct_atwould not have directly taken a void*

[carlosgalvezp]

would not have directly taken a void*

Exactly. It feels like placement new is a much cleaner solution already, no casts required.

[lcarlier]

https://en.cppreference.com/w/cpp/memory/construct_at.html

Construct_at is constexpr and consteval in C++26