This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [PATCH] Improve strncpy performance further
- From: "Wilco Dijkstra" <wdijkstr at arm dot com>
- To: "'Roland McGrath'" <roland at hack dot frob dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Sun, 11 Jan 2015 18:09:25 -0000
- Subject: RE: [PATCH] Improve strncpy performance further
- Authentication-results: sourceware.org; auth=none
- References: <001801d02b72$6ce0c3c0$46a24b40$ at com> <20150108185812 dot 285782C3BF6 at topped-with-meat dot com> <001901d02c0d$43cf9920$cb6ecb60$ at com> <20150109191632 dot 694692C3C1F at topped-with-meat dot com>
> Roland McGrath wrote:
> > Btw while on the subject on namespaces, is bcopy correctly defined?
> > After a lot of complex inclusion and defines, it ultimately does:
> >
> > void
> > bcopy ()
> > {
> > ...
> > }
>
> I'm not sure what kind of correctness you have in mind. bcopy is the only
> name under which that function needs to be defined. If it's in the same
> file as a standard function (presumably memmove) then it needs to be
> defined as weak. No other code anywhere in libc should call bcopy (we'd
> use memmove or memcpy instead), so it doesn't need to have an __ name.
Well, bcopy and bzero are both used in several non-test sources in GLIBC,
but one is always defined as __bzero, and the other as bcopy.
It's unclear to me what the exact namespace rules are (or whether there is
even a concise description of them somewhere), however it is obvious that
this is not consistent. Note any rule that relies on whether a function is
called or not from within the same library is risky unless you have
automated checks to catch that.
Wilco