On Wed, May 04, 2011 at 12:42:16AM -0500, Steve M. Robbins wrote: > On Wed, May 04, 2011 at 12:10:48AM -0500, Jonathan Nieder wrote: > > > Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518 > > which is fixed (sort of) by commit 0354e355 (2011-04-01). > > Oh my word. So glibc 2.13 breaks random binaries that happened to > incorrectly use memcpy() instead of memmove()? memcpy() has fat warnings about the areas not overlapping, and that's the very purpose of that function: a memmove() that is faster but less safe. > What's wrong with the glibc developers (and Ulrich Drepper in particular)? Nothing wrong, it is exactly the same as new compilers breaking behaviour forbidden by the standard that used to work before. The only problem is the breakage happening rarely, and thus being able to survive for long. > I'm with Linus on this: let's just revert to the old behaviour. A > tiny amount of clock cycles saved isn't worth the instability. I'd instead propose to sacrifice a tiny amount of cycles to check for overlapping and abort()ing so buggy code can be fixed. Random instability is the worst kind of error, a clean crash is easy to fix. Heck, we can even make a change just before wheezy is frozen to make it call memmove() when a breakage is detected. Just please don't paper over the bugs until then. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice.
Description: Digital signature