We already asserted that DBusMessageIter must be at least as large
as DBusMessageRealIter (so that casting DBusMessageIter * to
DBusMessageRealIter * does not result in overflowing the stack
variable). Also assert that it must have alignment requirements at
least as strict as those of DBusMessageRealIter * (so that casting
does not increase the required alignment).
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=94136
This is useful when making static assertions about our types'
properties.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=94136
The exception is test-autolaunch, which is really not particularly
useful as a build-time test. The only way we can really test
autolaunch is as a whole-system integration test, and "make check"
is not that.
The two tests written in Python and one test based on dbus-send
are also not run directly yet; in particular, that includes both
the tests in run-test-systemserver.sh.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Similar to commit 58eefa1031.
test-privserver is a helper executable, not a test. I moved its output
from stdout to stderr so it can't be misinterpreted as the test's
stdout.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Instead of using $DBUS_USE_TEST_BINARY to control whether to use the
hard-coded test binary TEST_BUS_LAUNCH_BINARY, we can just use
$DBUS_TEST_DBUS_LAUNCH to control what we launch directly, as we
were already doing for $DBUS_TEST_DAEMON.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
It is now possible to use msvc warnings identifiers
(e.g. '4114') or gcc warnings keys (e.g. 'pointer-sign').
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93069
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The exception is test-autolaunch, which is really not particularly
useful as a build-time test. The only way we can really test
autolaunch is as a whole-system integration test, and "make check"
is not that.
The two tests written in Python and one test based on dbus-send
are also not run directly yet; in particular, that includes both
the tests in run-test-systemserver.sh.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Similar to commit 58eefa1031.
test-privserver is a helper executable, not a test. I moved its output
from stdout to stderr so it can't be misinterpreted as the test's
stdout.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Instead of using $DBUS_USE_TEST_BINARY to control whether to use the
hard-coded test binary TEST_BUS_LAUNCH_BINARY, we can just use
$DBUS_TEST_DBUS_LAUNCH to control what we launch directly, as we
were already doing for $DBUS_TEST_DAEMON.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This makes it consistent with _dbus_message_loader_get_unix_fds().
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93069
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
libdbus uses dbus_bool_t for booleans; that type is unsigned 32-bit.
However, libapparmor uses int, which is signed, leading to
-Wpointer-sign warnings when we pass a dbus_bool_t * where an int *
was expected.
This file is Linux-specific, and all Linux platforms have 32-bit int
and an in-memory representation of the integers 0 and 1 that is
independent of signedness, so the previous code was harmless
in practice.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93069
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This fixes signedness mismatch warnings on platforms where socklen_t
is unsigned, notably Linux (where it's an unsigned int).
We still use int for the fallback case where the platform does not
define socklen_t, because that was the traditional (pre-POSIX) type:
for details see NOTES in Linux accept(2),
<http://manpages.debian.org/cgi-bin/man.cgi?query=accept&sektion=2>.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93069
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93908
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[smcv: Re-enable the failing test that Nick disabled, and fix the
expected result; the result given by our current implementation is
reasonable.]
dbus-daemon is not expected to open files with large *sizes*, but without
large file support, calling [f]stat() on a file that happens to have a
large inode number will fail with EOVERFLOW (see stat(2)). For example,
files mounted from an NFS server might have large inode numbers.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93545
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
[smcv: shorten and clarify commit message; move AC_SYS_LARGEFILE
after AC_USE_SYSTEM_EXTENSIONS because nothing should compile C before
that point]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The idea is that .travis.yml is specific to Travis-CI, but most of the
actual work is done in tools/ci-build.sh, which should be reasonably
CI-platform-agnostic (it currently assumes that build-dependendencies are
preinstalled, that the "native" platform we're building on is GNU/Linux
or something very close, and that "mingw" means mingw-w64 as packaged
in Debian and Ubuntu).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93194
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
We were mistakenly running all installed executables, even manual tests
that never terminate.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93194
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
A closing brace must be preceded by a semicolon. The CI integration
added later in this branch actually runs "make installcheck"
with no DESTDIR; apparently nobody else has ever tried that.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93194
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
With --systemd-activation we special-case the name
org.freedesktop.systemd1 by assuming that it will eventually connect
to the bus. With that in mind, we can ignore whether it has a
.service file, and let it be "activated" regardless.
This fixes a regression test failure on non-systemd systems such
as the Ubuntu 14.04 OS on travis-ci.org: UpdateActivationEnvironment
failed, because it tried to update the (fake) systemd environment,
but because systemd was not actually installed, there was no
service file for it in the system's search paths. We could address this
by placing a dummy service file with Exec=/bin/false in our search path
like the real systemd does, but it seems cleaner to not require this;
this would eventually enable the real systemd to stop installing
that dummy service file.
This would not happen outside the regression tests, because there is
no sense in using --systemd-activation without systemd installed.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93194
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
We documented DBUS_TEST_MALLOC_FAILURES=0 in HACKING, but it didn't
actually work: we'd iterate from i=-1 to i=0.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93194
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
For GLib-based tests it's useful, because it means g_test_message()
gets logged. For the embedded tests it's now accepted and ignored.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93194
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This makes them semi-command-line-compatible with a way we can
invoke the GLib-based tests to get more useful debug logs.
These tests still do not actually produce TAP output yet; I tried
implementing that, but it requires changing a lot of noise on stdout
to come out of stderr, and there was something weird going on with
subprocesses restarting the test numbering which will need further
investigation before making that change.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93194
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
