Glibc change exposing bugs

Well, actually, it IS kind of true... If the regions overlap (which is the sole
point of using memmove()), then it implies that the source region will indeed
no longer contain the data it previously contained, since at least part of it
would've been overwritten by the memmove() to the (overlapping) destination
region...

I side with the glibc people: any C programmer worth a damn knows better than
to use memcpy() on overlapping regions... Anyone that does so is writing known
buggy code that will fail to work on many systems... That it just happened to
have worked by chance until now on glibc doesn't matter a bit... There are
lots of subtle bugs you can make that appear to work fine until something
changes and exposes them... You see it in buffer overflows all the time; if
you overflow just a small amount and there's some meaningless variable there
in memory that you overflow into, no harm done, no crashing, no noticable bad
behavior at all... But, compile with a different optimization level, or change
the code in a certain way, and BAM!, that variable is no longer there to catch
the overflow, and you end up trashing something important... Now, are you
seriously going to say GCC should support such obviously buggy code by making
sure to always continue laying out variables in memory just as it did the
first time, so that the overflow causes no harm? If not, then how is this
glibc change any different at all?