Remaining issues? Wolfgang Corcoran-Mathe (09 Dec 2020 20:33 UTC)
Re: Remaining issues? Marc Nieper-Wißkirchen (10 Dec 2020 12:35 UTC)
Re: Remaining issues? Wolfgang Corcoran-Mathe (11 Dec 2020 18:11 UTC)
Re: Remaining issues? Marc Nieper-Wißkirchen (11 Dec 2020 19:05 UTC)
Re: Remaining issues? Marc Nieper-Wißkirchen (11 Dec 2020 19:20 UTC)
Re: Remaining issues? John Cowan (11 Dec 2020 22:02 UTC)
Re: Remaining issues? Wolfgang Corcoran-Mathe (11 Dec 2020 22:32 UTC)
Re: Remaining issues? Marc Nieper-Wißkirchen (12 Dec 2020 09:55 UTC)
Re: Remaining issues? Wolfgang Corcoran-Mathe (28 Dec 2020 19:15 UTC)
Re: Remaining issues? Marc Nieper-Wißkirchen (08 Jan 2021 14:34 UTC)

Re: Remaining issues? Marc Nieper-Wißkirchen 11 Dec 2020 19:20 UTC

Am Fr., 11. Dez. 2020 um 20:05 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de>:

> Now, on the positive side, by Annex J.3, every conforming
> implementation has to specify the number, order, and encoding of bytes
> in any object. For example, GCC specifies that this is specified by
> the ABI (https://gcc.gnu.org/onlinedocs/gcc/Architecture-implementation.html#Architecture-implementation).
> So given GCC and a suitable architecture (e.g. AMD64), one can make
> the conversion, at least through memcpy.

PS Using `memcpy` would be completely safe. However, given the
footnote (97) in
https://files.lhmouse.com/standards/ISO%20C%20N2176.pdf (which is not
normative), chances are very high that type-punning through a union
reinterprets the bytes in the same way as `memcpy` would.