use a CHAR_MIN-based array, like elsewhere in the code.
Remove a number of unused variables (some due to the above change, one
that was left after a number of optimizing steps through the source).
Brucified by: bde
remove (comment out) functions defined or depricated elsewhere:
bsearch, lfind, lsearch, insque, remque
change hcreate to take a size_t rather than uint (essentially the same)
since hcreate/hdestroy are now in <search.h>, remove private search.h
in lib/libc/db/hash/
add $FreeBSD tags to hsearch.c
- permit numeric scopeid, be more careful about buffer size
TODO: 2nd arg type should be socklen_t for RFC2553 conformance,
but due to include file dependency it is not a easy thing to do
(netdb.h does not have socklen_t)
soon to be committed syscall stubs. These calls will be used to get
and set capability state associated with executables.
Obtained from: TrustedBSD Project
interface addresses in a portable manner, without headache of SIOCGIFCONF
or sysctl. it is in bsdi/openbsd/netbsd already.
from kame tree (actually, mandatory for latest kame tree).
when parsing certain DNS records during a reverse address resolution. Thus
when code tries to examine the returned host name, it dereferences a null
pointer :-(
Problem noticed by: ps
VIS_HTTPSTYLE is a new encoding style for use in vis(), strvis() and
strvisx() that escapes characters according to RFC 1808 (URI encoding).
Since decoding of these require different detection of start-points of
escaped characters, VIS_HTTPSTYLE can be given as flag to unvis().
unvis() will then properly decode URIs.
A new function appeared, strunvisx(): strunvisx() behaves similar as
strunvis(), with one exception: It has an additional flag parameter,
which is passed to unvis() to archive the effect I described above.
previous commits.
At the time we search the pattern for the "must" string, we now compute
the longest offset from the beginning of the pattern at which the must
string might be found. If that offset is found to be infinite (through
use of "+" or "*"), we set it to -1 to disable the heuristics applied
later.
After we are done with pre-matching, we use that offset and the point in
the text at which the must string was found to compute the earliest
point at which the pattern might be found.
Special care should be taken here. The variable "start" is passed to the
automata-processing functions fast() and slow() to indicate the point in
the text at which they should start working from. The real beginning of
the text is passed in a struct match variable m, which is used to check
for anchors. That variable, though, is initialized with "start", so we
must not adjust "start" before "m" is properly initialized.
Simple tests showed a speed increase from 100% to 400%, but they were
biased in that regexec() was called for the whole file instead of line
by line, and parenthized subexpressions were not searched for.
This change adds a single integer to the size of the "guts" structure,
and does not change the ABI.
Further improvements possible:
Since the speed increase observed here is so huge, one intuitive
optimization would be to introduce a bias in the function that computes
the "must" string so as to prefer a smaller string with a finite offset
over a larger one with an infinite offset. Tests have shown this to be a
bad idea, though, as the cost of false pre-matches far outweights the
benefits of a must offset, even in biased situations.
A number of other improvements suggest themselves, though:
* identify the cases where the pattern is identical to the must
string, and avoid entering fast() and slow() in these cases.
* compute the maximum offset from the must string to the end of
the pattern, and use that to set the point at which fast() and
slow() should give up trying to find a match, and return then
return to pre-matching.
* return all the way to pre-matching if a "match" was found and
later invalidated by back reference processing. Since back
references are evil and should be avoided anyway, this is of
little use.
