Fixing the glibc adobe flash incompatibility

Fulko Hew fulko.hew at
Thu Nov 18 01:08:00 UTC 2010

On Wed, Nov 17, 2010 at 4:26 PM, Jeff Spaleta <jspaleta at> wrote:

> On Wed, Nov 17, 2010 at 8:16 PM, Jon Masters <jonathan at>
> wrote:
> > Did anyone upstream look into a compatibility environment variable that
> > could be exported to change the direction of the memcpy? Yes, it's a
> > hack, but it would allow affected users to have an option.
> Could we make use of that sort of environment variable feature more
> generally as a way to build environments that test for bad memcpy
> usage similar to this by flipflopping back and forth, even while we
> are writing code?

Its been a few decades since I last had to write a memcpy, but the last time
I did,
I made sure it worked with overlapping regions and just 'did the right
and made it as optimized as possible (for the CPUs available).

I know the definition for memcpy (on Linux) says don't use overlapping
regions but thats really a poor excuse for knowingly misbehaving when
it could certainly prevented.  Sorry, but using 'optimization' as a defense
is just plain poor engineering practices.

Its certainly easier to provide a single well-behaved memcpy than it is to
ensure that ALL programmers in the world write software that prevents
overlapping regions.

It may just be me, but wouldn't it be 'common sense'?
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the devel mailing list