On 15/02/17 11:30 +0000, Jonathan Wakely wrote:
On 14/02/17 21:42 -0500, Orcan Ogetbil wrote:
On 7 February 2017 at 16:32, Marek Polacek wrote:
libffado-2.3.0-1.fc26.src.rpm
sflphone-1.4.1-20.fc26.src.rpm
error: no matching function for call to ...
Invalid code.
I am 99% sure that these 2 errors are due to a bug in dbus-c++. Is the
new compiler attempting to compile (or verify) code in template
classes even if they are not initialized?
Yes, exactly. Previously GCC was fairly forgiving about broken
template code and would check almost nothing until the template was
instantiated. In more recent releases parts of the template which
don't depend on the template arguments get checked earlier. Clang has
been doing this for some time, but it's a more recent change for GCC.
I suspect that there is
broken code in the Threading class.
The standard says such code is ill-formed, but that no diagnostic is
required i.e. the compiler is allowed to diagnose the problem, but not
required to (because it could be expensive or difficult to check for
some compilers). So the code was always broken, but now GCC tells you
about it.
log:
-----
usr/include/dbus-c++-1/dbus-c++/dispatcher.h:262:5: error: no matching
function for call to '_init_threading(DBus::Mutex* (&)(), void
(&)(DBus::Mutex*), void (&)(DBus::Mutex*), void (&)(DBus::Mutex*),
DBus::CondVar* (&)(), void (&)(DBus::CondVar*), void
(&)(DBus::CondVar*, DBus::Mutex*), bool (&)(DBus::CondVar*,
DBus::Mutex*, int), void (&)(DBus::CondVar*), void
(&)(DBus::CondVar*))'
);
^
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:247:13: note: candidate:
void DBus::_init_threading()
void DXXAPI _init_threading();
^~~~~~~~~~~~~~~
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:247:13: note:
candidate expects 0 arguments, 10 provided
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:249:13: note: candidate:
void DBus::_init_threading(DBus::MutexNewFn, DBus::MutexFreeFn,
DBus::MutexLockFn, DBus::MutexUnlockFn, DBus::CondVarNewFn,
DBus::CondVarFreeFn, DBus::CondVarWaitFn, DBus::CondVarWaitTimeoutFn,
DBus::CondVarWakeOneFn, DBus::CondVarWakeAllFn) <near match>
void DXXAPI _init_threading(
^~~~~~~~~~~~~~~
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:249:13: note:
conversion of argument 3 would be ill-formed:
-----
see:
http://dbus-cplusplus.sourceforge.net/dispatcher_8h_source.html
The types MutexLockFn and MutexFreeFn depend on a macro:
#ifndef DBUS_HAS_RECURSIVE_MUTEX
typedef bool (*MutexFreeFn)(Mutex *mx);
typedef bool (*MutexLockFn)(Mutex *mx);
#else
typedef void (*MutexFreeFn)(Mutex *mx);
typedef void (*MutexLockFn)(Mutex *mx);
#endif//DBUS_HAS_RECURSIVE_MUTEX
But the type of the functions passed to _init_threading is always the
same:
static void mutex_free(Mutex *mx)
{
delete mx;
}
static void mutex_lock(Mutex *mx)
{
mx->lock();
}
That certainly looks suspicious.
More than suspicious. The DBus API docs at
https://dbus.freedesktop.org/doc/api/html/group__DBusThreads.html
seem to say that the MutexFreeFn should always return void (for the
recursive and non-recursive versions) but it depends on
DBUS_HAS_RECURSIVE_MUTEX here. MutexUnlockFn should depend on
DBUS_HAS_RECURSIVE_MUTEX, but is always the same type here.
Worse, the functions in the C++ API return bool, but the functions in
the C API return dbus_bool_t which is a typedef for dbus_uint32_t, so
the types don't match and calling them is undefined.
It looks like dbus-c++ is abandoned though, the upstream repo was at
gitorious.org which is gone.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
