News for hackers. Stuff that matters.
Re:Falsehoods programmers believe about undefined behavior by anonymoushn on Monday November 28, 2022 @08:54AM (#33773656)
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...

Re:Falsehoods programmers believe about undefined behavior by olliej on Monday November 28, 2022 @11:25AM (#33775589)
memcpy is UB because it reads padding bytes in structs.

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

Re:Falsehoods programmers believe about undefined behavior by anonymoushn on Monday November 28, 2022 @12:16PM (#33776306)
Sounds like we shouldn't use memcpy on structs containing padding!
Re:Falsehoods programmers believe about undefined behavior by maccard on Tuesday November 29, 2022 @10:59AM (#33789176)
No, memcpy is fine because it's a language level function. What you _can't_ do is implement your own memcpy alternative safely.
Re:Falsehoods programmers believe about undefined behavior by nayuki on Monday November 28, 2022 @01:18PM (#33777285)
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.
Re:Falsehoods programmers believe about undefined behavior by leni536 on Monday November 28, 2022 @05:26PM (#33780748)
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.