These changes are arbitrarily divided into multiple commits to make it
easier to find potentially introduced bugs with git bisect.
The modifications in this commit were automatically made using the
following command:
find . -name '*.h' -exec sed -i -E 's/dbg\(\) << ("[^"{]*");/dbgln\(\1\);/' {} \;
These changes are arbitrarily divided into multiple commits to make it
easier to find potentially introduced bugs with git bisect.Everything:
The modifications in this commit were automatically made using the
following command:
find . -name '*.cpp' -exec sed -i -E 's/dbg\(\) << ("[^"{]*");/dbgln\(\1\);/' {} \;
Problem:
- `constexpr` functions are decorated with the `inline` specifier
keyword. This is redundant because `constexpr` functions are
implicitly `inline`.
- [dcl.constexpr], §7.1.5/2 in the C++11 standard): "constexpr
functions and constexpr constructors are implicitly inline (7.1.2)".
Solution:
- Remove the redundant `inline` keyword.
Before, when the actually passed key was too long, the extra bytes were silently
ignored. This can lead to all sorts of trouble, so ... don't do that.
The original intention was maybe to support non-integer amounts of key bytes.
But that doesn't happen anyway with AES.
Any (future) program that includes this header would fail to compile, because the
private symbol 'kind_name' is defined, along with a bunch of code, but unused.
A good way to see this is by #include'ing LibCrypto/ASN1/ASN1.h in an unrelated
.cpp-file, for example Userland/md.cpp.
No other headers seem to have this problem.
If they use up so much stack space, contain (sometimes several) loops, and take
a noticable amount of time anyway, then 'inline' is probably going to be ignored
by the compiler anyway.
I originally defined the bytes() method for the String class, because it
made it obvious that it's a span of bytes instead of span of characters.
This commit makes this more consistent by defining a bytes() method when
the type of the span is known to be u8.
Additionaly, the cast operator to Bytes is overloaded for ByteBuffer and
such.
ByteBuffer::slice_view() allocates a new ByteBuffer object,
which as a RefPtr and everything.
Nowadays it should probably return a Bytes / Span<u8>, but AES was only
using slice_view() to extract the pointer again. So just add ady a
range check at the top, and do pointer arithmetic to do the same thing
faster.
Reduces time to run `disasm /bin/id` by a bit under 40%,
from ~8.3s to ~5s (min-of-3 runs).
This fixes the issue with the exported data having a leading zero,
causing RSA::encrypt to trim the block down, and ruining the encryption.
Fixes#2691 :^)
ModularFunctions::random_number calls into AK::fill_with_random calls (on
Serenity) into arc4random_buf calls into Process::sys calls into
get_good_random_bytes, which is cryptographically secure.
All the magic is happening in a "while != 0" loop, so we ended up with
an empty string for zero-value BigIntegers. Now we just check that
upfront and return early.
