Date: Mon, 6 Apr 2015 21:17:59 +0200 From: Olivier Houchard <mlfbsd@ci0.org> To: John-Mark Gurney <jmg@funkthat.com> Cc: freebsd-arm@FreeBSD.org Subject: Re: remove broken lib/libc/arm/string/memcpy_xscale.S Message-ID: <20150406191759.GA64102@ci0.org> In-Reply-To: <20150406190901.GW51048@funkthat.com> References: <20150405015245.GO51048@funkthat.com> <EBEF298E-38F7-49BA-8BFC-D8B61C0F0BBA@bsdimp.com> <20150406171248.GV51048@funkthat.com> <20150406174130.GA63423@ci0.org> <20150406190901.GW51048@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 06, 2015 at 12:09:01PM -0700, John-Mark Gurney wrote:
> Olivier Houchard wrote this message on Mon, Apr 06, 2015 at 19:41 +0200:
> > On Mon, Apr 06, 2015 at 10:12:48AM -0700, John-Mark Gurney wrote:
> > > Warner Losh wrote this message on Mon, Apr 06, 2015 at 09:58 -0600:
> > > > > On Apr 4, 2015, at 7:52 PM, John-Mark Gurney <jmg@funkthat.com> wrote:
> > > > >
> > > > > I would like to remove this file as it does not implement our defined
> > > > > memcpy. Per POSIX, overlapping regions passed to memcpy is undefined
> > > > > behavior. We have defined it to have the same symatics as memmove.
> > > > >
> > > > > Sample test program:
> > > > > #include <stdio.h>
> > > > > #include <string.h>
> > > > >
> > > > > char bufa[512] = "this is a test buffer that should be copied fine.";
> > > > > int
> > > > > main()
> > > > > {
> > > > >
> > > > > memcpy(&bufa[10], &bufa[0], strlen(&bufa[10]));
> > > > > printf("%s\n", bufa);
> > > > >
> > > > > return 0;
> > > > > }
> > > > >
> > > > > Output on amd64 HEAD:
> > > > > this is a this is a test buffer that should be co
> > > > >
> > > > > Output on old armv4 from 9.x:
> > > > > this is a this is a thst buffethst bufhould beufh
> > > > >
> > > > > If you just look at the file, it is clear that the implementation does
> > > > > not adjust the copy direction based upon pointers. We imported the
> > > > > code from NetBSD, and NetBSD does apparently require memcpy's arguments
> > > > > to be non-overlapping.
> > > > >
> > > > > I'll remove the file shortly unless someone can prove to me that all
> > > > > uses of memcpy in our tree do not depend upon our defined behavior
> > > > > per memcpy(3)'s man page.
> > > >
> > > > Any chance you can fix this implementation instead?
> > >
> > > I don't know arm assembly well enough, nor do I have the time to fix
> > > it.. I am willing to test any implementations as I have access to
> > > hardware...
> > >
> > > I guess I should add a test to verify that memcpy behavese like memmove
> > > to our test suite...
> > >
> >
> > I think the bug is in the manpage, not the code, and we should fix it the way
> > NetBSD did.
>
> Have you audited all of our code base to confirm that such a change
> will not break anything? The man page has been like this since r1573,
> so it's very possible that code has been written to depend upon this
> behavior...
>
No. But I doubt anybody decided to rely on an implementation detail described
in the "BUGS" section, written 25 years ago, to warn people NOT to do this.
If we do, well it's a bug, and it doesn't matter if it's in the manpage or not.
Both NetBSD and OpenBSD got ride of those bits, and so should we.
Olivier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150406191759.GA64102>