This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On 10 November 2010 17:25, Jed Brown <jed_at_[hidden]> wrote:
> Is the memcpy-back code ever executed when called as memcpy()? I can't
> imagine why it would be, but it would make plenty of sense to use it inside
> memmove when the destination is at a higher address than the source.
Oh yes. And, after further reading, it seems I'm not alone. There's an
article at http://lwn.net/Articles/414467/ about the new glibc changes
and a bug at https://bugzilla.redhat.com/show_bug.cgi?id=638477
relating directly to memcpy. The Fedora bug is particularly insightful
with some interesting contributions from Linus Torvalds himself,
In short, someone from Intel submitted a glibc patch that does faster
memcpy's on e.g. Intel i7, respects the ISO C definition, but does
things backwards. I think any software that ignores the ISO warning
"If copying takes place between objects that overlap, the behavior is
undefined" needs fixing.