This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/12518] memcpy acts randomly (and differently) with overlapping areas


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]