musl/src/string, branch v0.9.8 musl - an implementation of the standard library for Linux-based systems simplify logic in stpcpy; avoid copying first aligned byte twice 2012-10-22T19:17:09+00:00 Rich Felker dalias@aerifal.cx 2012-10-22T19:17:09+00:00 838951c97edc05cb2a25948ee542415b55b8f605 gcc seems to be generating identical or near-identical code for both versions, but the newer code is more expressive of what it's doing. 
gcc seems to be generating identical or near-identical code for both
versions, but the newer code is more expressive of what it's doing.
add memmem function (gnu extension) 2012-10-16T03:02:57+00:00 Rich Felker dalias@aerifal.cx 2012-10-16T03:02:57+00:00 c86f2974e2acd330be2d587173dd4dd56db82e22 based on strstr. passes gnulib tests and a few quick checks of my own. 
based on strstr. passes gnulib tests and a few quick checks of my own.
optimize strchrnul/strcspn not to scan string twice on no-match 2012-09-27T21:19:09+00:00 Rich Felker dalias@aerifal.cx 2012-09-27T21:19:09+00:00 68dbd05039f8b256f586ed9a589645fa3a1b7f5f when strchr fails, and important piece of information already computed, the string length, is thrown away. have strchrnul (with namespace protection) be the underlying function so this information can be kept, and let strchr be a wrapper for it. this also allows strcspn to be considerably faster in the case where the match set has a single element that's not matched. 
when strchr fails, and important piece of information already
computed, the string length, is thrown away. have strchrnul (with
namespace protection) be the underlying function so this information
can be kept, and let strchr be a wrapper for it. this also allows
strcspn to be considerably faster in the case where the match set has
a single element that's not matched.
slightly cleaner strlen, also seems to compile to better code 2012-09-27T20:56:33+00:00 Rich Felker dalias@aerifal.cx 2012-09-27T20:56:33+00:00 3f9ff1514e49b06c20a61af9ae9e52bd53b48d9a testing with gcc 4.6.3 on x86, -Os, the old version does a duplicate null byte check after the first loop. this is purely the compiler being stupid, but the old code was also stupid and unintuitive in how it expressed the check. 
testing with gcc 4.6.3 on x86, -Os, the old version does a duplicate
null byte check after the first loop. this is purely the compiler
being stupid, but the old code was also stupid and unintuitive in how
it expressed the check.
asm for memmove on i386 and x86_64 2012-09-10T23:04:24+00:00 Rich Felker dalias@aerifal.cx 2012-09-10T23:04:24+00:00 2bf469310de6793228c103691859ed4d3158b117 for the sake of simplicity, I've only used rep movsb rather than breaking up the copy for using rep movsd/q. on all modern cpus, this seems to be fine, but if there are performance problems, there might be a need to go back and add support for rep movsd/q. 
for the sake of simplicity, I've only used rep movsb rather than
breaking up the copy for using rep movsd/q. on all modern cpus, this
seems to be fine, but if there are performance problems, there might
be a need to go back and add support for rep movsd/q.
reenable word-at-at-time copying in memmove 2012-09-10T22:16:11+00:00 Rich Felker dalias@aerifal.cx 2012-09-10T22:16:11+00:00 1701e4f3d46b14c4c4be8a46e64f8eaf15a5c061 before restrict was added, memove called memcpy for forward copies and used a byte-at-a-time loop for reverse copies. this was changed to avoid invoking UB now that memcpy has an undefined copying order, making memmove considerably slower. performance is still rather bad, so I'll be adding asm soon. 
before restrict was added, memove called memcpy for forward copies and
used a byte-at-a-time loop for reverse copies. this was changed to
avoid invoking UB now that memcpy has an undefined copying order,
making memmove considerably slower.

performance is still rather bad, so I'll be adding asm soon.
use restrict everywhere it's required by c99 and/or posix 2008 2012-09-07T02:44:55+00:00 Rich Felker dalias@aerifal.cx 2012-09-07T02:44:55+00:00 400c5e5c8307a2ebe44ef1f203f5a15669f20347 to deal with the fact that the public headers may be used with pre-c99 compilers, __restrict is used in place of restrict, and defined appropriately for any supported compiler. we also avoid the form [restrict] since older versions of gcc rejected it due to a bug in the original c99 standard, and instead use the form *restrict. 
to deal with the fact that the public headers may be used with pre-c99
compilers, __restrict is used in place of restrict, and defined
appropriately for any supported compiler. we also avoid the form
[restrict] since older versions of gcc rejected it due to a bug in the
original c99 standard, and instead use the form *restrict.
remove dependency of wmemmove on wmemcpy direction 2012-09-07T00:28:42+00:00 Rich Felker dalias@aerifal.cx 2012-09-07T00:28:42+00:00 bac03cdde1137c16b4c194e137310e2748661dcc unlike the memmove commit, this one should be fine to leave in place. wmemmove is not performance-critical, and even if it were, it's already copying whole 32-bit words at a time instead of bytes. 
unlike the memmove commit, this one should be fine to leave in place.
wmemmove is not performance-critical, and even if it were, it's
already copying whole 32-bit words at a time instead of bytes.
remove dependency of memmove on memcpy direction 2012-09-07T00:25:48+00:00 Rich Felker dalias@aerifal.cx 2012-09-07T00:25:48+00:00 594318fd3d13c7dda1ea87a76934e052ac74301f this commit introduces a performance regression in many uses of memmove, which will need to be addressed before the next release. i'm making it as a temporary measure so that the restrict patch can be committed without invoking undefined behavior when memmove calls memcpy with overlapping regions. 
this commit introduces a performance regression in many uses of
memmove, which will need to be addressed before the next release. i'm
making it as a temporary measure so that the restrict patch can be
committed without invoking undefined behavior when memmove calls
memcpy with overlapping regions.
memcpy asm for i386 and x86_64 2012-08-12T01:33:13+00:00 Rich Felker dalias@aerifal.cx 2012-08-12T01:33:13+00:00 aaa9eb5101e3a748218fb9373dd9655b50582da2