Is std::memcpy between different trivially copyable types undefined behavior?

The standard may fail to say properly that this is allowed, but it’s almost certainly supposed to be, and to the best of my knowledge, all implementations will treat this as defined behaviour.

In order to facilitate the copying into an actual char[N] object, the bytes making up the f object can be accessed as if they were a char[N]. This part, I believe, is not in dispute.

Bytes from a char[N] that represent a uint32_t value may be copied into an uint32_t object. This part, I believe, is also not in dispute.

Equally undisputed, I believe, is that e.g. fwrite may have written the bytes in one run of the program, and fread may have read them back in another run, or even another program entirely.

Because of that last part, I believe it does not matter where the bytes came from, as long as they form a valid representation of some uint32_t object. You could have cycled through all float values, using memcmp on each until you got the representation you wanted, that you knew would be identical to that of the uint32_t value you’re interpreting it as. You could even have done that in another program, a program that the compiler has never seen. That would have been valid.

If from the implementation’s perspective, your code is indistinguishable from unambiguously valid code, your code must be seen as valid.

Leave a Comment

Hata!: SQLSTATE[08004] [1040] Too many connections