| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
The C implementation of str{,r}chr are not linked to the build, because
assembly implementations are used, but change to code for easier reference.
At least the i386 and amd64 are checked and seem to do the correct thing.
Found thanks to the csh any/strchr change.
minor pointers and OK millert@
|
| |
|
|
|
|
|
|
|
|
|
|
| |
wrapper .h files and asm labels to let internal calls resolve directly and
not be overridable or use the PLT. Then, apply that framework to most of
the functions in stdio.h, string.h, err.h, and wchar.h. Delete the
should-have-been-hidden-all-along _v?(err|warn)[cx]? symbols while here.
tests clean on i386, amd64, sparc64, powerpc, and mips64
naming feedback from kettenis@ and millert@
ok kettenis@
|
| |
|
|
|
| |
part of the ISO C standard and have also been dropped from POSIX.
OK guenther@ kettenis@
|
|
|
(potentially) MD versions (function dependent, not filename dependent)
split out memcpy/memmove/bcopy and strchr/index/strrchr/rindex
Bring back amd64 .S versions
And the final touch: switch all architectures temporarily to MI
memcpy.c, which contains syslog + abort for overlapping copies. A nice
harsh undefined behaviour. We will clean the entire userland of the
remaining issues in this catagory, then switch to the optimised memcpy
which skips the memmove check.
I tried to cut this change into pieces, but testing each sub-step on
every architecture is too time consuming and mindnumbing.
ok miod
|
