dbus-send.1: use bold and italic type consistently

According to man-pages(7)

* bold is for literal text, the name of the thing being documented,
  or the name of another man page

* italic is for replaceable text, usually in all-caps

* normal type (in the SYNOPSIS) is for special syntax like the []
  indicating optional things

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=14005
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Lennart Poettering <lennart@poettering.net>
dbus-send.1, dbus-send: document --print-reply=literal consistently

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=14005
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Lennart Poettering <lennart@poettering.net>
dbus-send.1: document --reply-timeout

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=14005
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Lennart Poettering <lennart@poettering.net>
NEWS
dbus-protocol.h: compile under C++11

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>
NEWS for 1.4
Merge branch 'dbus-1.4'

Conflicts:
	NEWS
Fixed runtime error caused by using uninitialized variable detected with msvc build.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46335
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Make _dbus_mutex_new, _dbus_mutex_free static

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>
Distinguish between two flavours of mutex

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>
Allow both recursive and non-recursive mutexes to be supplied

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>
Use actual recursive pthreads mutexes, rather than NIH'ing them, wrong

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: improve documentation

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>
Never use non-libdbus threading primitives

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>
Remove _dbus_condvar_wake_all and both of its implementations

Neither was used, and the Windows version could lead to live-locks.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=43744
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=44609
Reviewed-by: Thiago Macieira <thiago@kde.org>
_dbus_verbose_real: tidy conditional prototype to not break nesting

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>
Remove declaration of _dbus_type_is_fixed, no longer exists

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46095
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
Add a macro to centralize checking for string-like types

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46095
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
internal_bus_get: centralize error handling

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46095
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
Invoke PKG_PROG_PKG_CONFIG early in configure.ac

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>