On Thu, Jul 07, 2005 at 07:42:37PM +0200, Andy Polyakov wrote:
> >1) In openssl-0.9.8/crypto/des/cfb_enc.c line 170 there is "memcpy
> >(ovec,ovec+num,8);" and since ovec and ovec+num will overlap sometimes,
> >this function relies on undocumented/undefined behavior of memcpy?

> The original reason for choosing of memcpy was a) it's comonly inlined
> by compilers [most notably gcc], but not memmove, b) I fail to imagine
> how it can fail with overlapping regions if num is guaranteed to be
> positive, even if the routine is super-optimized, inlined, whatever. Can
> you?

This doesn't make any sense - if memcpy can handle overlapping regions
without any slowdown, then wouldn't it make sense to implemenent
memmove as a #define (or inline call to) memcpy? Either memcpy does
not handle overlaps while memmove does, or memcpy and memmove work at
the same speed, because the ability to handle overlapping memory
regions is the only difference between the two. The only other
alternative is that memcpy and memmove do the exact same thing, but
memmove is slower. That seems quite unlikely.

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org