GCC 15 tightened its built-in declarations for strchr() and strstr() so
that they now propagate const from their first argument, triggering
-Werror=discarded-qualifiers on three assignments in string.c:
translate():
char *match = strchr(from, *pos)
`from` is const char *, so the result of strchr() is const char *.
`match` is only used for pointer arithmetic (match - from), so
declaring it const char * is correct and safe.
strreplace():
found = strstr(str, search) [line ~73]
found = strstr(pos, search) [line ~89, while condition]
`str`/`pos` are derived from a const char * parameter, so strstr()
returns const char *. `found` is used as a mutable char * later
(pos = found + slen), consistent with the existing (char*) casts
already used throughout this function for the same reason.
Add explicit (char*) casts to match the established pattern.
Closesstrongswan/strongswan#3015
Clean up leak-detective whitelist for newer Botan versions but add
`botan_private_key_load` as `botan_privkey_load*` won't show up anymore
without bfd-backtraces due to inlining if we don't call it directly.
Ref: https://github.com/randombit/botan/discussions/4868
When cross-compiling for Windows on Ubuntu, we don't have POSIX regular
expressions available (there does not seem to be any alternative libraries
either), but since the tests are not executed that's OK. On AppVeyor,
MSYS2 has libgnurx installed, which works fine but requires explicit
linking with `-lregex`.
This is loosely based on a patch by Thomas Egerer.
As described in the previous commit, GCC 15 uses C23 by default and that
changes the meaning of such argument-less function declarations. So
whenever we assign such a function to a pointer that expects a function
with arguments it causes an incompatible pointer type warning. We
could define dedicated functions/callbacks whenever necessary, but this
seems like the simpler approach for now (especially since most uses of
these functions have already been cast).
AWS-LC (and likely BoringSSL) uses thread specific data to store internal
library state which gets freed via a registered destructor when the thread
terminates. If this thread happens to be the main thread, which runs the
leak-detective evaluation, the detective won't observe the corresponding free
of the related memory and erroneously reports it as a leak.
The two places this happens are:
- `RAND_bytes` for storing internal RNG state.
- `ERR_put_error` for storing the per-thread OpenSSL error queue.
References strongswan/strongswan#1907Closesstrongswan/strongswan#2147
systemd seems to use this and if we indirectly use libraries provided
by it, which can e.g. happen via getgrnam_r() and nss-systemd, this may
be called on pointers returned by leak detective's malloc(), which will
not point to the original start of the block and cause a segmentation
fault.
Closesstrongswan/strongswan#2045
The all-zero Ed25519 public key is rejected by botan_pubkey_check_key()
when the key is loaded.
Note that Botan 3 requires GCC 11 or CLANG 14, i.e. can't easily be built
on Debian bullseye or Ubuntu 20.04.
The thread-local storage function gets flagged via various botan FFI
functions when using Botan 3, whitelist that instead of all of them.
Some variables that are only assigned to be used in DBG statements
will otherwise trigger a "set but not used" warning/error if DEBUG_LEVEL
is too low.
At least since Ubuntu 22.04 there are lots of (apparently non-fatal)
"DWARF error: could not find variable specification" errors generated
by bfd_find_nearest_line(). This also happens with addr2line, which
internally uses libbfd. No idea what the actual issue is (it still
happens with binutils 2.39 in Ubuntu 22.10), but since it doesn't seem
to affect the functionality we need this avoids filling the test logs
with useless messages.
A recent change added CALLBACK to PENUM_PAGE_FILE_CALLBACKW/A in psapi.h,
which conflicts with our own macro of the same name. Our compat/windows.h
header undefs the Windows definition, but that only works if Windows
headers are included before ours, which wasn't the case for psapi.h.
This forces the use of a semicolon after INIT() and makes existing ones,
which was the case for basically all instances, necessary so e.g.
sonarcloud won't complain about an empty statement after every one of
them.
By evaluating to the allocated object, it would theoretically also allow
constructs like this:
struct_t *this;
return INIT(this,
.a = x,
.b = y,
);
or this:
array_insert(a, ARRAY_TAIL, INIT(this,
.a = x,
.b = y,
));
Tobias Brunner