The empty string does not match anywhere. In other implementations of
string replacement, an empty string matches at every position of the
source string.
This only works for the :S modifier. The :C modifier does not allow an
empty search pattern.
This simple change reduces the binary size of var.o by 96 bytes (Clang,
x86_64). Given that the code is still the same, just in a different
order, this is a bit surprising.
If there is no matching interface given, but interface matching is enabled
then all interfaces on the system will try to be initialized.
Non wireless interfaces will fail and the loopback device will be one
of these, so just log a diagnostic rather than an error.
However, unfortunately, this does not fix strange crashes of GCC8-compiled
kernel, for which I cannot even enter DDB nor obtain crash dump.
We need further investigation...
In both parts of the :@ modifier, by passing &pflags to
ParseModifierPart, a final $ was interpreted as an anchor, which only
makes sense in the :S and :C modifiers.
This edge case is neither used by src nor by pkgsrc, except for the unit
tests that have been adjusted.
Reporting keys on every lookup is overkill unless
playing with a new HASH, so wrap in #ifdef DEBUG_HASH_LOOKUP
Also add some stats at the end so we can see
final size and max chain length - maxchain is a better
variable name than maxlen.
We need to find the lwp that was originally interrupted to save its
fpu state.
With this, fpu-heavy programs (like firefox) are once again stable,
at least under modest stress testing, on systems configured to use
wifi with WPA2 and CCMP.
This way fpu_kern_enter/leave cannot interrupt the transition, so the
transition from state-on-CPU to state-in-memory (with TS set) is
atomic whether in an interrupt or not.
(I am not 100% convinced that this is necessary, but it makes
reasoning about the transition simpler.)
The expression word + wordLen - leftLen had resulted in an out-of-bounds
pointer before. Luckily the heap addresses were high enough in typical
applications to prevent a wrap-around.
There's a bug in the FPU state handling that it triggers -- likely
limited to the softint path since I've only ever seen it on a system
using wifi configured with WPA2 and CCMP, which uses AES heavily in
softint.
This is to be reverted once we diagnose the bug. (There is also a
performance regression on wifi with WPA2 and CCMP, which I plan to
fix too once we figure out the FPU state handling bug.)
