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 [email protected]
Automated List Manager [EMAIL PROTECTED]
