Fixing the glibc adobe flash incompatibility

[Gregory Maxwell]

On Wed, Nov 17, 2010 at 10:03 PM, Chris Adams <cmadams at hiwaay.net> wrote:
[snip]
> shouldn't be done in a "stable" release of glibc.  Is memcpy called
> often enough (and on large enough blocks) that this change makes a real
> performance difference (not just on a synthetic memcpy benchmark)?

Most code is not performance critical. However, performance critical
code is performance critical.

Memcpy bottle-necked workloads aren't that uncommon.  If you've got
one you want every piece of memcpy performance possible, if you don't
have one then you won't care.  Every single performance thing is like
this. They add up.


If Fedora wanted to carry a patch against GLIBC it could carry one
that crashed any application that called memcpy with overlapping
inputs. Every one of these bugs would be fixed right quickly.  (FWIW,
I think the old memcpy would also fail on overlaps, but it would tend
to corrupt the ends and only if the ends were within four bytes of
each other and the length was one less than a multiple of four or
something like that).  It's probably a reasonable guess that anything
using memcpy incorrectly has other errors arising from a failure to
understand and follow the relevant APIs.

Although it seems like an easy mistake to make— I've valgrinded a lot
of code and never seen the valgrind warning for this. I don't think
it's actually common.  It might be useful to first measure before
worrying too much about this.