<font face="courier new,monospace"><br></font><br><div class="gmail_quote">On Wed, Nov 17, 2010 at 4:26 PM, Jeff Spaleta <span dir="ltr"><<a href="mailto:jspaleta@gmail.com">jspaleta@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, Nov 17, 2010 at 8:16 PM, Jon Masters <<a href="mailto:jonathan@jonmasters.org">jonathan@jonmasters.org</a>> wrote:<br>
> Did anyone upstream look into a compatibility environment variable that<br>
> could be exported to change the direction of the memcpy? Yes, it's a<br>
> hack, but it would allow affected users to have an option.<br>
<br>
Could we make use of that sort of environment variable feature more<br>
generally as a way to build environments that test for bad memcpy<br>
usage similar to this by flipflopping back and forth, even while we<br>
are writing code?<br></blockquote><div><br>Its been a few decades since I last had to write a memcpy, but the last time I did,<br>I made sure it worked with overlapping regions and just 'did the right thing'<br>and made it as optimized as possible (for the CPUs available).<br>
<br>I know the definition for memcpy (on Linux) says don't use overlapping<br>regions but thats really a poor excuse for knowingly misbehaving when<br>it could certainly prevented. Sorry, but using 'optimization' as a defense<br>
is just plain poor engineering practices.<br></div></div><br>Its certainly easier to provide a single well-behaved memcpy than it is to<br>ensure that ALL programmers in the world write software that prevents<br>overlapping regions.<br>
<br>It may just be me, but wouldn't it be 'common sense'?<br><br><br>