This only affects malformed RSA keys. Instead of accepting and
continuing with potentially broken pointers (and in ASAN, crashing), we
now consider bitmaps malformed, and stop parsing.
Found by OSS Fuzz: #31698, long-standing-bug:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31698
Fun fact: The "if" only exists because of OSS Fuzz.
8cc279ed74
Problem:
- Static variables take memory and can be subject to less optimization
(https://serenityos.godbolt.org/z/7EYebr1aa)
- This static variable is only used in 1 place.
Solution:
- Move the variable into the function and make it non-static.
Problem:
- Clang ToT reports an error because `digest_size` cannot be evaluated
at compile-time.
Solution:
- Change from using the member function to the `static` shadow of the
NTTP.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
This flag warns on classes which have `virtual` functions but do not
have a `virtual` destructor.
This patch adds both the flag and missing destructors. The access level
of the destructors was determined by a two rules of thumb:
1. A destructor should have a similar or lower access level to that of a
constructor.
2. Having a `private` destructor implicitly deletes the default
constructor, which is probably undesirable for "interface" types
(classes with only virtual functions and no data).
In short, most of the added destructors are `protected`, unless the
compiler complained about access.
This is basically just for consistency, it's quite strange to see
multiple AK container types next to each other, some with and some
without the namespace prefix - we're 'using AK::Foo;' a lot and should
leverage that. :^)
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED)
Since all of these checks are done in release builds as well,
let's rename them to VERIFY to prevent confusion, as everyone is
used to assertions being compiled out in release.
We can introduce a new ASSERT macro that is specifically for debug
checks, but I'm doing this wholesale conversion first since we've
accumulated thousands of these already, and it's not immediately
obvious which ones are suitable for ASSERT.
