This allows people to still write statically linked applications that
call strchr() or strrchr() and have a local variable or function called
index.
Discussed with: bde@
As I looked through the C library, I noticed the FreeBSD MIPS port has a
hand-written version of index(). This is nice, if it weren't for the
fact that most applications call strchr() instead.
Also, on the other architectures index() and strchr() are identical,
meaning we have two identical pieces of code in the C library and
statically linked applications.
Solve this by naming the actual file strchr.[cS] and let it use
__strong_reference()/STRONG_ALIAS() to provide the index() routine. Do
the same for rindex()/strrchr().
This seems to make the C libraries and static binaries slightly smaller,
but this reduction in size seems negligible.
On anything modern, the C version, which processes a word at a time, is much
faster. The Intel optimization manual explicitly warns against using REP
prefixes with SCAS or CMPS, which is exactly what the assembler version
does.
A simple test on a Phenom II showed the C version, compiled with -O2, to be
about twice as fast determining the length of 100000 strings between 0 and
255 bytes long.
MFC after: 2 weeks
re-read from the stack mid copy. This may help mitigate the recent
Apache buffer overrun and future overruns of the sort.
Reviewed by: jdp
MFC after: 2 days
The names of m-d variants are now added (manually) to MDSRCS instead
of to SRCS, and the names of all machine-independent (m-i) variants
that can reasonably be replaced by an m-d variant are now added
(manually) to MISRCS instead of to SRCS, so that a simple substitution
can be used to discard the unused m-i variants. MISRCS is potentially
all m-i sources, but the substitution is too simple to be fast, so
MISRCS should be kept reasonably small.
libc/Makefile.inc:
Do the substitution.
libc/i386/string/Makefile.inc:
Add to MDSRCS instead of to SRCS. Add the names of all sources in this
directory, but no others.
libc/string/Makefile.inc
Add to MISRCS instead of to SRCS. Add the names of all sources in this
directory. Don't use (broken) explicit rules for special cases.
the (buggy) support for alternative entry points. ALTENTRY() was only
used for memmove(). Optimizing for space was particularly silly because
memcpy() is rarely used (gcc normally inlines it).
Obtained from: NetBSD
the (buggy) support for alternative entry points. ALTENTRY() was only
used for memmove(). Optimizing for space was particularly silly because
memcpy() is rarely used (gcc normally inlines it).
Obtained from: NetBSD
- use a slightly less bogus copyright. This file was never contributed
to Berkeley. It still claims to be copright by the Regents.
- use <machine/asm.h> instead of "DEFS.h".
- use RCSID($Id$) instead of explicit assembly code and messy ifdefs.
The rcsid won't be put into the object file until we make RCSID()
non-null. NetBSD uses a LIBC_SCCS ifdef here. We used a LIBC_RCS
instead, but I want RCSID() to be controlled directly by LIBC_RCS
(actually by LIB_RCS). This is the only difference with the NetBSD
version.
- added ifdefs to support generation of memcpy() and memmove(). The
other changes are "while I'm here" to get this.
- improved style of the copy backwards case.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
is really necessary. Going backwards on a P6 is much slower than forwards
and it's a little slower on a P5. Also moved the count mask and 'std'
down a few lines - it's a couple percent faster this way on a P5.
1) Changed LIB_SCCS and SYSLIB_SCCS to LIB_RCS and SYSLIB_RCS.
2) Changed sccsid[] variables to rcsid[]
3) Moved all RCSID strings into .text
4) Converted all SCCSID's to RCS $Id$'s
5) Added missing $Id$'s after copyright.
pointer if len is 0. I should have looked at the revision history - I would
have found that Bruce already fixed the bug with len=0 over a month ago.
Whoever said that the bug was in 2.0 was wrong.
