In mingw-w64 both ESOMETHING and WSASOMETHING are defined,
leading to a duplicate case in the switch.
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=47321
g_thread_init() is deprecated since glib 2.24, call g_type_init() instead.
Bump glib requirement accordingly.
g_thread_create is deprecated since 2.31, use g_thread_new() instead. When
building with a glib earlier than 2.31, provide a backwards compatibility shim.
[Added a comment about why we're using g_type_init() in a test that
doesn't otherwise use GObject -smcv]
[Applied to 1.4 despite just being a deprecation fix because it also fixes
linking with GLib 2.32, in which gthread has been removed from gobject's
Requires and moved to Requires.private, Debian #665665 -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=44413
Bug-Debian: http://bugs.debian.org/665665
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The "unixexec:" transport will create a local AF_UNIX socket with
socketpair(), then fork and execute a binary on one side with STDIN and
STDOUT connected to it and then use the other side.
This is useful to implement D-Bus tunneling schemes, for example to get
a D-Bus connection to the system bus on a different host, similar how
udisks is already doing it. (udisks uses SSH TCP tunneling for this,
which is a bit ugly and less secure than this solution).
Suggested use is with connection strings like the following:
unixexec:path=ssh,argv1=foobar,argv2=system-bus-bridge
or:
unixexec:path=pkexec,argv1=system-bus-bridge
or even:
unixexec:path=sudo,argv1=system-bus-bridge
The first line would execute the binary 'system-bus-bridge' on host
'foobar' and then pass D-Bus traffic to it. This (hypothetical) bridge
binary would then forward the information to the local system bus.
The second and third line use this scheme locally to acquire a
privileged connection through pkexec resp. sudo: instead of connecting
directly to the bus, they use the same bridge binary which will forward
all information to the system bus.
The arguments of the protocol are 'path' for the first execlp()
argument, and argv0, argv1, and so on for the following arguments. argv0
can be left out in which case path will be used.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35230
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This is optimized on Linux and enumerates through /proc/self/fd with a
fallback on brute-force closing of fds, in case /proc is not available.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35230
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The DBusPipe code was broken by commit 6e214b5b3c, which switched
from C runtime API to Win32 API for WinCE's benefit. In a DBusPipe,
fd_or_handle is in fact always a C runtime file descriptor, which can't
be used with the Win32 API (which expects a HANDLE).
This commit goes back to the C runtime API. It might cause WinCE support
to regress, but at least dbus-daemon.exe --print-address works again.
This is enough to make a few tests work under Wine when cross-compiling
from Linux to mingw-w64: in particular, this now works:
DBUS_TEST_DAEMON=bus/dbus-daemon.exe DBUS_TEST_DATA=test/data \
wine test/test-dbus-daemon.exe -p /echo/session
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
dbus_bool_t is the same as dbus_uint32_t, but if we have a separate
bool_val member, it's more obvious that people are getting it right.
It's not called bool because that's a keyword in C++.
int (for file descriptors) doesn't appear in the D-Bus message wire
format, but then again neither does char *, and
dbus_message_iter_get_basic() and friends can return an int (due to
internal index-into-array-of-fds -> fd remapping in libdbus).
In theory int might not be the same size as any of the dbus_intNN_t
types, and anyway it's easier to see that people are getting it right
if we make it explicit.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=11191
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
In practice, D-Bus bindings end up reinventing DBusBasicValue anyway,
so it might as well be API.
Also stop claiming that all basic-typed values are guaranteed to fit in
8 bytes - this is not true if your platform has more than 8-byte pointers
(I'm not aware of any such platform now, but let's not rule it out).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=11191
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
This test needs non-public API and so is statically linked, but is OK
to install.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=42811
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
--enable-modular-tests=auto will build as many as possible, perhaps
excluding the GLib ones. --enable-modular-tests=yes or --enable-tests=yes
will insist on having GLib, to be able to run everything.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=42811
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If tests are enabled and DBUS_MALLOC_CANNOT_FAIL is set, abort on system
malloc() failures (as GLib's g_malloc does). This can be used in
conjunction with a resource limit, to turn runaway memory leaks into a
debuggable core-dump.
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41048
Recent gcc will warn if you have a statement that's just a macro
expanding to (0), but not if you have an inline stub function that
always returns 0, so let's do the latter.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=37286
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
This means the bus test can use them without needing
dbus-message-private.h, reducing its view of message internals.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46095
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
Otherwise, autoconf can generate wrong code, because our first use of
PKG_CHECK_MODULES is conditional.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46095
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
The mismatched opening parenthesis caused vim syntax highlighting to
consider every subsequent brace in the file to be an error, which was
pretty annoying.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46095
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
This lets us simplify considerably, by assuming that we always have both
recursive and suitable-for-condition-variable mutexes.
The Windows implementation has been compiled (on 32-bit mingw-w64)
but not tested. Justification for the approach used on Windows,
and in particular, using the existing "non-recursive" locks as if
they were recursive:
* We've been using them in conjunction with condition variables all
along, so they'd better be suitable
* On fd.o #36204, Ralf points out that mutexes created via CreateMutex
are, in fact, recursive
* Havoc's admonitions about requiring "Java-style" recursive locking
(waiting for a condition variable while holding a recursive lock
requires releasing that lock n times) turn out not to apply to
either of our uses of DBusCondVar in DBusConnection, because the
lock is only held for a short time, without calling into user code;
indeed, our Unix implementation isn't recursive anyway, so if
the Windows implementation reaches the deadlocking situation
somehow (waiting for condition variable while locked more than once),
the Unix implementation would already have deadlocked on the same
code path (trying to lock more than once)
One possible alternative to a CreateMutex mutex for use with condition
variables would be a CRITICAL_SECTION. I'm not going to implement this,
but Windows developers are welcome to do so.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=36204
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=43744
Reviewed-by: Thiago Macieira <thiago@kde.org>
This reinstates documentation for _dbus_mutex_new() and
_dbus_mutex_free(), and fixes some typos spotted during review.
It also documents the newly-introduced functions.
Reviewed-by: Thiago Macieira <thiago@kde.org>
Very loosely based on a patch from Sigmund Augdal.
For the moment, we make PTHREAD_MUTEX_RECURSIVE a hard requirement:
it's required by POSIX 2008 Base and SUSv2.
If your (non-Windows) platform doesn't have PTHREAD_MUTEX_RECURSIVE,
please report a bug on freedesktop.org bugzilla with details of the
platform in question.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=43744
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Thiago Macieira <thiago@kde.org>
dbus-threads.h warns that recursive pthreads mutexes are not compatible
with our expectations for condition variables. However, the only two
condition variables we actually use only have their corresponding
mutexes locked briefly (and we don't call out to user code from there),
so the mutexes don't need to be recursive anyway. That's just as well,
because it turns out our implementation of recursive mutexes on
pthreads is broken!
The goal here is to be able to distinguish between "cmutexes" (mutexes
compatible with a condition variable) and "rmutexes" (mutexes which
are recursive if possible, to avoid deadlocking if we hold them while
calling user code).
This is complicated by the fact that callers are not guaranteed to have
provided us with both versions of mutexes, so we might have to implement
one by using the other (in particular, DBusRMutex *aims to be*
recursive, it is not *guaranteed to be* recursive).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=43744
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Thiago Macieira <thiago@kde.org>
They're only called within their module.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=43744
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Thiago Macieira <thiago@kde.org>
C++11 compilers have a feature called 'user-defined string literals' which
allow arbitrary string suffixes to have user-defined meaning.
This makes code that concatenates macros with string literals without
intervening whitespace illegal under C++11. Fortunately, string literal
concatenation has allowed intervening whitespace since the dawn of time,
so the solution is to simply pad with spaces.
Tested (header) with GCC 4.7 (trunk).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46147
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
