© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
So is there any real reason to believe that memmove() can't just be as fast as memcpy?
Seriously. That's what it all boils down to. Why have a separate memcpy() at all, when it clearly is correct - and nice to people - to always just implement it as a memmove(). And I really don't see the downside. It's not like it's going to be slower.
People who want to check whether their application is portable can use valgrind, the same way you have to check for portability issues in other areas (eg the extra glibc specific printf formats etc - they just "work", but they certainly aren't portable).
So why not just be nice.
If anything, from a "be nice" standpoint, it would perhaps be good to have a "debug mode", that would actually _warn_ - or even assert - about overlapping memcpy(). That obviously shouldn't be the default (since that only helps developers), but it would be along the same lines of the nice malloc debugging help that glibc can give.
IOW, I think this is an area where glibc can be _better_ than what is required of it.