This would have caused the test to fail if `DBUS_TEST_DBUS_MONITOR` was
not specified in the environment. Handily, it is always set by the
`meson.build` file.
Spotted by jvpeetz.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #424
This version is required for glib-based tests with AF_UNIX support
under Windows.
As dbus is at the beginning of a new development branch and 2.72
is quite old (2022), the minimum version has been unconditionally
raised.
Unix domain sockets are used if the host on which dbus is running
supports this. Due to this change, the minimum supported glib2
version on Windows is 2.72.
Makes the meson config match what the autotools config used to do.
v2: include changes suggested by @smcv to allow disabling if desired
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Instead of hardcoding these as always needed, test to see, since
they're not needed on Solaris 11.4, but are on older versions & illumos.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
dbus/dbus-pollable-set-epoll.c currently errors out if __linux__ is not
defined. Allows passing -Depoll=enabled to override.
Based on patch by Jonathan Perkin for pkgsrc on illumos:
https://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/sysutils/dbus/patches/patch-meson.build?rev=1.2
but modified to only change default of 'auto' and check for all non-Linux OSes.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Checking the uid of the user seat also works if elogind is used. Add
this as an option to the build and make it mutually exclusive with
enabling systemd.
Fix an off by one error which could produce a tv_nsec value of
1'000'000'000. The valid tv_nsec range is [0, 999,999,999], see
https://en.cppreference.com/w/c/chrono/timespec for reference.
Passing a timespec with a tv_nsec value of 1'000'000'000 to
pthread_cond_timedwait has been observed to cause it to return an error
code which in turn makes the DBUS library abort the application when
compiled with asserts enabled (by PTHREAD_CHECK).
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/556
Reviewed-by: Simon McVittie <smcv@collabora.com>
14.2 reaches end-of-life in September, and our 14.2-based image has a
sufficiently small amount of space available that it fails to upgrade
now.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We recommend that assertions are disabled in production builds of dbus,
which means that they are "cheap" to add to development builds as
"executable documentation" for our assumptions.
Lower-level code assumes that timeouts must be either -1 to block
forever, or non-negative to block for a finite time (but possibly 0,
to poll without blocking).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously we were checking for -1 as the special-cased "block forever"
value, but as noted on dbus!524 it is a programming error to call
_dbus_condvar_wait_timeout() with any negative timeout.
Throughout DBusConnection the timeout is in fact constrained to be >= -1
(non-negative to have a timeout, or exactly -1 to block forever) but
checking for non-negative is presumably no more expensive than checking
for exactly -1, so let's be a little more defensive here, to make it
more obvious that we're doing this correctly.
This is the only caller of _dbus_condvar_wait_timeout() in our codebase.
Signed-off-by: Simon McVittie <smcv@collabora.com>
As noted in dbus!524 by source code inspection, the Unix/pthread
implementation assumes that the timeout is non-negative and does not
support a mode where it blocks forever (which we normally represent as
a negative timeout, like POSIX poll(2)).
This means that it would be a programming error if we ever call
this with a negative timeout, so put an equivalent assertion in the
platform-independent layer. We recommend that assertions are disabled in
production builds, so it's "cheap" to have a redundant assertion here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We should never allocate a DBusTimeout with a negative timeout set:
if we want to wait forever for an event to happen, that's represented
by the absence of a DBusTimeout.
This ensures that code in DBusConnection can safely assume that the
timeout retrieved from a DBusTimeout will always be in its allowed range
(-1 to INT_MAX inclusive).
I've checked that all current callers get this right.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Getting into the `if (timeout == NULL)` block means that
timeout_milliseconds == -1, so it doesn't make sense to do arithmetic on it.
Pass -1 instead of a nonsensical value in this case
