Fixing the glibc adobe flash incompatibility
fulko.hew at gmail.com
Thu Nov 18 01:08:00 UTC 2010
On Wed, Nov 17, 2010 at 4:26 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Wed, Nov 17, 2010 at 8:16 PM, Jon Masters <jonathan at jonmasters.org>
> > 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 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
It may just be me, but wouldn't it be 'common sense'?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel