This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/12518] memcpy acts randomly (and differently) with overlapping areas
- From: "torvalds at linux-foundation dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Fri, 25 Feb 2011 04:15:03 +0000
- Subject: [Bug libc/12518] memcpy acts randomly (and differently) with overlapping areas
- Auto-submitted: auto-generated
- References: <bug-12518-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=12518
--- Comment #3 from Linus Torvalds <torvalds@linux-foundation.org> 2011-02-25 04:14:39 UTC ---
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.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.