<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">&lt;<a href="mailto:jspaleta@gmail.com">jspaleta@gmail.com</a>&gt;</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 &lt;<a href="mailto:jonathan@jonmasters.org">jonathan@jonmasters.org</a>&gt; wrote:<br>
&gt; Did anyone upstream look into a compatibility environment variable that<br>
&gt; could be exported to change the direction of the memcpy? Yes, it&#39;s a<br>
&gt; 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 &#39;did the right thing&#39;<br>and made it as optimized as possible (for the CPUs available).<br>

<br>I know the definition for memcpy (on Linux) says don&#39;t use overlapping<br>regions but thats really a poor excuse for knowingly misbehaving when<br>it could certainly prevented.  Sorry, but using &#39;optimization&#39; 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&#39;t it be &#39;common sense&#39;?<br><br><br>