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

[Rodney W. Grimes]

> On Mon, Feb 13, 2017 at 9:04 PM, Mark Millard <markmi at dsl-only.net> wrote:
> > 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.]
> 
> Seems like the memcpy man page should be softened to reflect the !x86
> reality. If we provide different semantics between different arches,
> we should consider carefully why and document in the code or change.

We should consider that we never do that, please, that is just asking
for a lot of foot shooting!   Especially with something as fundemental
as memcpy/bcopy!


-- 
Rod Grimes                                                 rgrimes at freebsd.org