On Wed, Nov 17, 2010 at 4:26 PM, Jeff Spaleta <jspaleta@xxxxxxxxx> wrote:
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 thing'
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.
On Wed, Nov 17, 2010 at 8:16 PM, Jon Masters <jonathan@xxxxxxxxxxxxxx> 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 thing'
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'?
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
