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: Tue, 29 Mar 2011 14:43:33 +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 #17 from Felipe Contreras <felipe.contreras at gmail dot com> 2011-03-29 14:43:31 UTC ---
Actually, why not have both? I think this plan would fit everyone:
1) Apply Linus' patch
Both to 2.13 and 2.14, this would not introduce any issues and would restore
back the previous behavior, so applications would still work. As I mentioned
before, the disadvantages are minimal.
2) Apply H.J. Lu's patch
This would go to 2.14, but not only to x86 but all architectures, and add an
overlap check, and when triggered issue a crash.
This would allow old binaries to keep working on 2.14, but newly compiled ones
would crash if they are doing something wrong. This would allow all the users
of glibc to fix their code for the impending changes.
3) Remove overlap checks
On 2.15, after a transition period, the overlap checks can be removed, and thus
save the few extra cycles.
This has all the advantages of all the proposals, and makes it easy to fix the
applications that are using memcpy wrong.
--
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.