News for hackers. Stuff that matters.
Re:Clang emits memcpy for std::swap, which can introduce und... by haberman on Sunday April 24, 2016 @09:20PM (#11562102)
I can't see an argument here for why the standard should be changed. memcpy() does one thing and memmove() does another. Changing the standard so they are the same just because memcpy() gets misused in real-world programs doesn't make sense to me. If people misuse memcpy(), then have a compiler flag akin to -fstrict-aliasing where memcpy() gets rewritten to memmove() unless people compile with -fstrict-memcpy.

That seems a separate issue though from what calls the compiler should emit. I am not following why LLVM would emit memcpy() when the semantics it actually requires from libc are memmove(). Am I missing something?

Re:Clang emits memcpy for std::swap, which can introduce und... by Joky on Monday April 25, 2016 @12:18AM (#11562499)
It is not about making memcpy behave the same as memmove: in this case the difference would still be between exact identity (src == dest) and partial overlap.
Re:Clang emits memcpy for std::swap, which can introduce und... by haberman on Monday April 25, 2016 @12:58AM (#11562558)
I see, thanks for clarifying. I agree there could be reason to consider a change in that case.