Interesting that Linus didn't patch it by simply calling memmove with the same arguments and passing back the same return.
Interesting that no-one's suggested we fix the obviously ambiguous wording in the man page. It seems that trusting the C programmer to know the difference between memcpy and memmove - whose names do _not_ imply anything about their behaviour - is a bad thing. Rusty's Hierarchy of API Design scores another victim, and yet no-one wants to fix either the API, the documentation or the behaviour.
Interesting that the question of why backwards-copying is necessary remains (AFAICS) unanswered. Has anyone actually tested whether the loop can be written with a forwards-copy and whether it performs better or worse than the backwards-copy and/or the Linus brute-force method?
Interesting that everyone who doesn't want to change memcpy to do checks or warn or everything asserts, without much actual evidence, that it would be a Bad Thing. Citation needed, or at least some crude benchmarks or numbers.
In my uninformed opinion it would be better to have one version of memcpy (memmove implies that the memory is absent from the source once completed, which is not true) that does the checks. The tiny overhead will be nothing compared to the page faults you're almost certainly incurring with repeated use. Run some tests, real world or otherwise, to see whether it really makes any difference. If it doesn't, make memmove a defined alias for memcpy, update the documentation, and everyone wins. The API remains the same, badly written applications don't die because of an underlying implementation change, lazy programmers have their arses saved, everyone wins.