"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?
"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?