This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: bzero/bcopy/bcmp/mempcpy (was: Improve strncpy performance further)
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Wilco Dijkstra <wdijkstr at arm dot com>
- Cc: 'Roland McGrath' <roland at hack dot frob dot com>, <libc-alpha at sourceware dot org>
- Date: Wed, 14 Jan 2015 17:24:10 +0000
- Subject: RE: bzero/bcopy/bcmp/mempcpy (was: 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> <001a01d02dc9$bd6f0370$384d0a50$ at com> <20150113191449 dot AD91B2C39DC at topped-with-meat dot com> <001e01d03003$f67b8670$e3729350$ at com>
On Wed, 14 Jan 2015, Wilco Dijkstra wrote:
> Roland McGrath wrote:
> > There are no uses of bcopy outside of tests, and portability macros in code
> > (possibly, or once) shared with gnulib. There is a bcopy macro in
> > locale/programs/simple-hash.c, but it's not used anywhere. I've removed
> > that in the patch below.
> >
> > There are three uses of bzero outside of tests. I've changed those to
> > memset in the patch below. In my build (x86_64-linux-gnu, GCC 4.8.3) this
> > did not change the compiled code at all--so they were already being reduced
> > to memset or inlined directly by the compiler.
>
> GCC often expands bzero into memset, but not all versions do this, and neither
> do all options, so you cannot rely on this. So before your patch login/logout.c
> might actually call bzero...
glibc only supports building with a limited set of compilers, and the
semantic options used for the build must be those determined by glibc's
built system (it's not valid to include -fno-builtin in CC or CFLAGS when
configuring glibc, for example).
> We need something like this in string.h so we always optimize all calls to
> standard optimized functions, irrespectively of the compiler and options used:
We hardly *need* such an optimization, when it's only for obscure cases of
old code and unusual compiler options. (It may still be a good idea, if
done correctly.)
> #ifdef __USE_MISC
> # define bzero(s, n) memset (s, '\0', n)
> # define __bzero(s, n) memset (s, '\0', n)
> # define bcopy(src, dest, n) memmove (dest, src, n)
These all need casts to void so as to return the correct types.
--
Joseph S. Myers
joseph@codesourcery.com