This fixes a -Wcast-align warning from Clang, and I believe this could
be a genuine issue on some architectures since the octets argument is
an unsigned char pointer that only has alignment 1. Using memcpy() instead
will generate the same code on architectures that support unaligned loads
and stores (i.e. almost all current ones) and individual stores on those
that don't (e.g. old MIPS).
Clang performs the -Wcast-align analysis before code generation and
optimizations, so the compiler cannot see that the alignment is actually
guaranteed to be sufficient for these casts. Silence the warning by adding
casts to void* and/or changing the types of some variables.
CMake 3.21 can emit JUnit XML test results which can be visualized by
GitLab. This also updates the gitlab CI config file to make use of this
feature whenever possible.
dbus-sysdeps-unix.c checks for DBUS_USE_SYNC using 0/1 checks not defined
checks, so we should be using #cmakedefine01. This fixes lots of -Wundef
warnings when compiling for FreeBSD and ensures that we actually use
atomics instead of the pthread fallback there.
The CI templates include infrastructure to create docker images with all
packages specified in tools/ci-install.sh. Using those docker images
speeds up the CI since we don't have to install all the dependencies in
every pipeline. We could extend this to also create containers that have
mingw pre-installed but for now we only create an image with the
dependencies that are required for every job.
The tests are enabled with the embedded tests; the required
low-level functions from the dbus library are decorated with
DBUS_EMBEDDED_TESTS_EXPORT to indicate the appropriate usage.
On Windows, all tests are run; on unix-like operating systems,
individual tests are disabled:
- the tests on #NULL pointers of type DBus[C|R]Mutex, since they
point to a data structure and would cause a segment violation
when accessed.
- the multiple lock test for type DBusCMutex, since it would block
the current thread.
Since the whole point of "rmutex" is to be able to lock multiple
times, the "rmutex double lock" test is enabled on unix-like
operating systems too.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
This detects some error conditions that can only occur as a
result of a programming error, such as attempting to unlock a
mutex that is not locked.
Fixes#369
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
To avoid that build break in test-marshall-recursive-util.c the newly
added function _dbus_string_append_buffer_as_hex() is used to print
the hex bytes.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
This function provides a portable way to print data as hex values.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
[smcv: Only compile this when needed, improve assertions, coding style]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Unlike the rest of the macros in dbus-macros.h, this one would never
have made sense to use in a public header.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This avoids a circular dependency: I want to use
DBUS_ENABLE_EMBEDDED_TESTS in dbus-string.h, but
DBUS_ENABLE_EMBEDDED_TESTS was previously defined in dbus-internals.h,
which depends on dbus-string.h.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Unsupported warnings are detected by cmake through errors during
compilation, which causes g++ not to detect them, since they are
only output as warnings. Setting -Werror ensures this.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
As long as gcc does something with compatible semantics, it is up to gcc
how to optimize our code.
The alternative would be to export the functions in question from the
shared library, which has the disadvantage of greatly increasing the
number of calls across a shared library boundary.
Part-of: https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/275
Reviewed-by: Simon McVittie <smcv@collabora.com>
gcc 10.3 warns that link->data is a possible NULL dereference.
However, that can't actually happen without an earlier programming
error, because bus_service_remove_owner() is only valid to call for
a connection that is currently in the queue to own the service,
in which case we know _bus_service_find_owner_link() will succeed.
Part-of: https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/275
Reviewed-by: Simon McVittie <smcv@collabora.com>
To fix this problem, the problematic code was replaced by a new function
_dbus_string_get_allocated_size(), which uses the existing macro
DBUS_CONST_STRING_PREAMBLE for these purposes.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Part-of: https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/275
Reviewed-by: Simon McVittie <smcv@collabora.com>
gcc 10.3 warns that link->data might be NULL, which would make
new_owner->conn a null pointer dereference. However, we know that
we only add valid, non-null BusOwner objects to the list, so that
can't happen in reality.
Part-of: https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/275
Reviewed-by: Simon McVittie <smcv@collabora.com>
Only do the deliberate crash via undefined behaviour (which the compiler
is quite right to warn us about!) if raise() isn't available.
The pointer needs to be volatile otherwise the compiler is free to remove
the store.
Part-of: https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/275
Reviewed-by: Simon McVittie <smcv@collabora.com>
This was added to the Linux kernel in version 5.9, but the wrapper
wasn't added to glibc until 2.34. Adding our own wrapper for the
system call means we can use close_range() on Debian 11 and
contemporary distributions.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This lets us use CLOSE_RANGE_CLOEXEC whenever the kernel headers
support it, even if glibc doesn't include this header via unistd.h yet.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The version with no flags set, which is a slight generalization of
closefrom(), is available on recent Linux and FreeBSD.
The version with CLOSE_RANGE_CLOEXEC is Linux-specific.
Signed-off-by: Simon McVittie <smcv@collabora.com>
closefrom() is known to be async-signal-safe on FreeBSD, NetBSD and
OpenBSD, and safe to call after fork() on Solaris, but not necessarily
on DragonflyBSD.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Without this running, dbus-daemon with long XDG_DATA_DIRS
will crash on out-of-bounds write:
$ XDG_DATA_DIRS=$(seq -f "/foo/%g" -s ':' 129) dbus-daemon --session
*** stack smashing detected ***: terminated
Using PRId64, etc. to print dbus_int64_t or dbus_uint64_t is not 100%
portable. On platforms where both long and long long are 64-bit (such as
Linux and macOS), we will prefer to define dbus_int64_t as long.
If the operating system has chosen to define int64_t as long long,
which is apparently the case on macOS, then the compiler can warn that
we are passing a long argument to PRId64, which is "lld" and therefore
expects a long long argument (even though that ends up with the same
bit-pattern being used).
We can't necessarily just use int64_t and uint64_t directly, even if all
our supported platforms have them available now, because swapping
dbus_int64_t between long and long long might change C++ name mangling,
causing ABI breaks in third-party libraries if they define C++ functions
that take a dbus_int64_t argument.
Signed-off-by: Simon McVittie <smcv@collabora.com>
