Theres a big difference between "the GCC mailing list is full of language lawyers" and "memcpy doesn't work because UB and the compiler Devs fixed it by adding an exception for it".

> I think aliasing rules messes up memcpy if you are dogmatic?

I'm _not_ dogmatic or a language lawyer and aliasing is a total pain in the ass, but that's a whole different topic to compilers getting fundamentals wrong because of language lawyering.

To be fair it is extremely easy to write broken C/C++ program

I think memcpy is fine because it operates on a special type that is allowed to alias anything. Strict aliasing has other fun issues like the impossibility of implementing malloc-like functions or the lack of any requirement for access to non-char members of structs to work at all[0].

[0]: https://stackoverflow.com/questions/49298704/how-reason-abou...

memcpy is UB because it reads padding bytes in structs.

memmove fails as it requires pointer comparisons between separate allocations, which is UB.

Sounds like we shouldn't use memcpy on structs containing padding!

No, memcpy is fine because it's a language level function. What you _can't_ do is implement your own memcpy alternative safely.

memcpy() and memmove() are language-level functions. They are allowed to do things that cannot be implemented in user code. The C standard library's implementation of these functions have tight integration with the compiler to ensure that it can implement all the required semantics without triggering undefined behavior.

reading padding bytes is not UB.

Comparing unrelated pointers is unspecified, not undefined. It's also an implementation detail of memmove. It can use a magical total order comparison of pointers that is otherwise unavailable to users of the language.