String is defined as an array of char. The char can be negative. The
cast "reinterpret_cast" from char to int keep the negative side, so
the "unsigned char" number 0x91 is negative as "char". When it is
"reinterpret_cast" as integer, it becomes 0xffffff91, so the hexadecimal
display is broken:
[155493246391.747672] [/absolute?what=badarg2] [9] T (0) t:hexEncode: "ffffff91ffffffecffffffe6334bffffffebffffff87ffffff9affffff824a06ffffffc33b4cffff (14 characters omitted)"
This patch fix this behavior using classic cast without reinterpret_cast:
[155493251286.221115] [/absolute?what=badarg2] [9] T (0) t:hexEncode: "91ece6334beb879a824a06c33b4cb4240e4c6f56"
When LMDB is enabled, ModSecurity stores its persistent variables in
"./modsec-shared-collections" file. Since this file wasn't cleared between
tests, tests behaved differently on "in-memory per-process" and LMDB backend.
This test never worked in LMDB configuration. It hasn't been discovered
until now because Travis CI didn't test LMDB configuration when test was
introduced.
LMBD is not built by default since 6143eb9,
so add explicit --with-lmdb configuration.
Missing --with-lmdb build allowed a bug in PR #2003 to pass
through, causing issue #2008.
This commit fixes quite a few odd things in regex code:
* Lack of encapsulation.
* Non-method functions for matching without retrieving all groups.
* Regex class being copyable without proper copy-constructor (potential UAF
and double free due to pointer members m_pc and m_pce).
* Redundant SMatch::m_length, which always equals to match.size() anyway.
* Weird SMatch::size_ member which is initialized only by one of the three matching
functions, and equals to the return value of that function anyways.
* Several places in code having std::string value instead of reference.
