buf(9) woes: when does bcopy do nothing at all?

Warner Losh imp at bsdimp.com
Mon Apr 29 13:59:19 UTC 2019


On Fri, Apr 26, 2019 at 12:44 PM Mark Millard via freebsd-hackers <
freebsd-hackers at freebsd.org> wrote:

> On 2019-Apr-26, at 01:32, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> > --------
> > In message <
> CAOtMX2gdw+eQQU_-DC+EgimbCyw6ynbX1haGLUmn1dApk4rMZw at mail.gmail.com>, Alan
> Somers writes:
> >
> >> How is it possible that bcopy() doesn't affect its output array at all?
> >
> > That conclusion does not follow from your example:
> >
> >> bcopy(cp, iov->iov_base, cnt);
> >> r = memcmp(cp, iov->iov_base, cnt);
> >> if (r)
> >>   printf("uiomove: miscompare\n");
> >
> > If [cp:cp+cnt] and [iov_base:iov_base+cnt] overlap the bcopy result
> > is undefined.
> >
> > Try memmove instead ?
>
> I only see a bcopy man page bcopy(3) but it says:
>
> DESCRIPTION
>      The bcopy() function copies len bytes from string src to string dst.
> The
>      two strings may overlap.  If len is zero, no bytes are copied.
>
> Is a kernel bcopy likely to be any different?
>

kernel bcopy works with overlapping strings. It's always done this on x86,
and different archs behaved different, so we fixed that so the all handle
it properly. memcpy is still an issue here, potentially, but memmove isn't.

But it was also reported things weren't overlapping, etc. so that's not the
issue.

Warner


More information about the freebsd-hackers mailing list