Our current coding style is not very uniform and we don't seem to be
following any particular standard, even though there are some patterns
we more or less follow.
This attempts to mostly reproduce our current style. However, it still
introduces quite a lot of changes since clang-format doesn't yet support
dangling parentheses[*] (where the closing parenthesis of a parameter
list goes on its own line).
[*]: https://reviews.llvm.org/D33029
Hi,
currently tests don't build with MSVC, because the Base64 test tries to initialize multiple arrays with a length value that was derived from a non-const context. I have fixed this by using vectors instead.
Sincerely
Johannes Hayeß
From 2d76972a862f0aa04b5011537bef71a49aa82a03 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Johannes=20Haye=C3=9F?= <jhaye@mailbox.org>
Date: Sun, 27 Jun 2021 17:46:24 +0200
Subject: [PATCH] Fix compiling with MSVC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Previously attempts to initialize arrays with non-const value. This
seemingly works on GCC/clang due to their static code analysis, but
fails with MSVC. This switches to dynamic memory allocation with
std::vector, to solve the problem.
Signed-off-by: Johannes Hayeß <jhaye@mailbox.org>
This type of instrumentation is much faster (several times over) and
supports much more features than afl-gcc/afl-g++, though it requires
a LLVM/clang installation.
olm::decode_base64 now returns the length of the raw decoded data on
success. When given input with an invalid base64 length, it fails early
(before decoding any input) and returns -1.
This also makes the C function _olm_decode_base64 an actual binding of
olm::decode_base64 instead of a wrapper with slightly different
behaviour.
_olm_decode_group_message should initialize all fields of the results
struct before returning. This is because its caller
_decrypt_max_plaintext_length relies on it having initialized these
fields.
Luckily, this only allows one to subvert the version check in
_decrypt_max_plaintext_length, but not the following check that the
ciphertext field is non-null because that field *is* initialized.
Consider the case when the input is size 0. In this case, `count` and
`buffer_pos` will be 0 as well. The `realloc` call in the `count == 0`
branch will then effectively become a free.
However, `realloc` can sometimes return `NULL` when a 0 is passed for
the size. The current code assumes that this only happens on a memory
allocation error and breaks out of the loop. This then becomes a double
free because the buffer is freed a second time, causing an abort.
The intent of the `realloc` is probably to downsize the buffer to fit
the data exactly in order to make incorrect memory access more obvious.
This commit skips this downsizing if the size of the input data is 0.
