>>>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?


Do note "[when] num [as in memcpy(ovec,ovec+num,8)] is guaranteed to be
positive." Question was can you imagine memcpy implementation that would
fail to handle overlapping regions when source address is *larger* than
destination? Question was *not* if you can imagine memcpy implementation
that would fail to handle arbitrary overlapping regions.

> 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.


See a). Inlining is believed/expected to be faster than call to a
function. For example in the referred case in particular inline memcpy
can be compiled as two 32-bit loads followed by two stores on IA-32.
memmove call on the other hand shall involve register spills, putting
arguments and return address to stack, branch, pulling arguments,
comparing them, etc., etc., etc. A.
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org