Date: Wed, 27 Aug 2025 08:03:41 -0500
On Wed, Aug 27, 2025, at 01:19, Paul Caprioli via Std-Proposals wrote:
>> Arduino Uno and Atmega-based devices are prominent examples where double is a 32 bit float.[1] I believe this is because they do not have a 64-bit FPU. Same with avr-gcc.[2]
>> Can we reinterpret_cast double to a float32_t on these platforms?
>
> I don't immediately see in those docs whether or not the 32-bit float
> is IEEE binary32.
> For the sake of discussion, let's assume it is.
> The docs do say that float and double are identical representations.
> Then the proposal would be to allow reinterpret_cast of pointers
> between float, double, and std::float32_t to work.
You want static_cast here not reinterpret_cast. If that is paper it should be revised. Reinterpret_cast has always been "hey compiler, trust me that these bits don't really mean what the type says they mean, treat them as this other type and shut up about it". Static_cast has always been you know how to treat these bits in a different way, so please apply that (error if you don't know how). In your example it makes no difference as the two types happen to have the same bits.
In systems where float/double is not ieee-754 there is a big difference. static_cast from non-pointers should convert between the two representations (bike shed question: should this be an implicate conversion no cast need, cast needed, or separate function unrelated to casting - I favor the last but it is a bikeshed question not on topic here), or it should fail to compile. When working with pointers the static_cast needs to fail to compile thus informing developers they have a real bug in their code. Reinterpret_cast in these systems will change the type without touching the bits - despite the underlying bits being nonsense after the change.
The only reason you would want reinterpret_cast that I can come up with is if you have a heterogeneous system (network?) and whoever did the IPC is sending double and won't let you fix it. You can wrap their library, taking float64_t reinterpret_cast to double and pass it to their library, thus ensuring only ieee754 is used on the network. There might be other reasons as well, but for all of them I hope nobody encounters them in the real world - but I want that escape to exist anyway just in case.
>> Arduino Uno and Atmega-based devices are prominent examples where double is a 32 bit float.[1] I believe this is because they do not have a 64-bit FPU. Same with avr-gcc.[2]
>> Can we reinterpret_cast double to a float32_t on these platforms?
>
> I don't immediately see in those docs whether or not the 32-bit float
> is IEEE binary32.
> For the sake of discussion, let's assume it is.
> The docs do say that float and double are identical representations.
> Then the proposal would be to allow reinterpret_cast of pointers
> between float, double, and std::float32_t to work.
You want static_cast here not reinterpret_cast. If that is paper it should be revised. Reinterpret_cast has always been "hey compiler, trust me that these bits don't really mean what the type says they mean, treat them as this other type and shut up about it". Static_cast has always been you know how to treat these bits in a different way, so please apply that (error if you don't know how). In your example it makes no difference as the two types happen to have the same bits.
In systems where float/double is not ieee-754 there is a big difference. static_cast from non-pointers should convert between the two representations (bike shed question: should this be an implicate conversion no cast need, cast needed, or separate function unrelated to casting - I favor the last but it is a bikeshed question not on topic here), or it should fail to compile. When working with pointers the static_cast needs to fail to compile thus informing developers they have a real bug in their code. Reinterpret_cast in these systems will change the type without touching the bits - despite the underlying bits being nonsense after the change.
The only reason you would want reinterpret_cast that I can come up with is if you have a heterogeneous system (network?) and whoever did the IPC is sending double and won't let you fix it. You can wrap their library, taking float64_t reinterpret_cast to double and pass it to their library, thus ensuring only ieee754 is used on the network. There might be other reasons as well, but for all of them I hope nobody encounters them in the real world - but I want that escape to exist anyway just in case.
Received on 2025-08-27 13:04:06