bcopy/memmove optimization broken ? [looks like you are correct to me, I give supporting detail]

[Mark Millard]

On 2017-Feb-13, at 1:27 AM, Mark Millard <markmi at dsl-only.net> wrote:

> As the decision about when to call the code that can
> deal with overlapping memory regions is wrong, the code
> that should only be used for non-overlaping regions likely
> would handle some overlapping regions and so would operate
> incorrectly in at least some cases.
> 
> In other words, I think the bug is worse than just an
> example of being sub-optimal: the code is wrong from what
> I can tell. (I've no clue if the code is ever put to use
> for any bad cases.)

I was wrong about the error status, possibly for multiple reasons,
but the following is sufficient:

https://www.freebsd.org/cgi/man.cgi?query=memcpy&sektion=3

says:

     In this implementation memcpy() is	implemented using bcopy(3), and	there-
     fore the strings may overlap.  On other systems, copying overlapping
     strings may produce surprises.  Programs intended to be portable should
     use memmove(3) when src and dst may overlap.

so the branch taken case for:

bcc PIC_SYM(_C_LABEL(memcpy), PLT)

also deals with overlaps since FreeBSD criteria is
that memcpy does so. (I had been thinking that it
did not deal with such.)


Side note:

Notably the arm implementation of FreeBSD memcpy does not call
bcopy (that would be recursive in the arm implementation).
memcpy just needs to have some properties that bcopy also has.

This suggests that memcpy vs. bcopy may have a performance
Principle of Least Astonishment violation since memcpy may well
perform differently than bcopy for some types of contexts but
memcpy is supposed to use bcopy.


[A varient of these notes are in the comments for bugzilla
217065.]

===
Mark Millard
markmi at dsl-only.net