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: "felipe.contreras at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Thu, 3 Mar 2011 23:27:57 +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
Felipe Contreras <felipe.contreras at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |felipe.contreras at gmail
| |dot com
--- Comment #8 from Felipe Contreras <felipe.contreras at gmail dot com> 2011-03-03 23:27:33 UTC ---
"Buggy" code can be linked to the new memcpy@@GLIBC_2.14 by just recompiling,
no? That doesn't really solve anything.
Sure, code should use memcpy correctly, and if glibc has a compelling reason to
break these programs, it should. As Ulrich mentions in comment #4 "There are
going to be more and different implementations in the future and they shouldn't
be prevented from being used because of buggy programs."
But _today_ that's not the case. Today, the regression can be fixed easily with
a patch like what Linus is proposing, and there will be no *downside*
whatsoever.
How about glibc breaks the behavior _only_ when there's an *upside* to breaking
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.