Right now we warn on these constructs: #ifdef DBUS_HAVE_INT64 /* I think I probably mean "GNU libc printf" and not "GNUC" * but we'll wait until someone complains. If you hit this, * just turn off verbose mode as a workaround. */ #if __GNUC__ _dbus_verbose (" u64: 0x%llx", *(dbus_uint64_t*)&data[i-8]); "llx" here is wrong; like all the printf formatters, it is for a variable size type (long long int, which is only defined to be *at least* 64 bits - it could be larger). What we need are internal macros similar to GLib's G_INT64_FORMAT etc.
Created attachment 34329 [details] [review] 0001-Add-DBUS_GNUC_PRINTF-checks-to-new-formatting-functi.patch
Created attachment 34330 [details] [review] 0002-Add-DBUS_INT64_MODIFIER-define-turn-on-Wformat.patch
Comment on attachment 34329 [details] [review] 0001-Add-DBUS_GNUC_PRINTF-checks-to-new-formatting-functi.patch This looks fine.
Comment on attachment 34330 [details] [review] 0002-Add-DBUS_INT64_MODIFIER-define-turn-on-Wformat.patch dbus_uid_t and dbus_pid_t have format macros DBUS_UID_FORMAT and DBUS_PID_FORMAT; shouldn't they be used rather than casting uids and pids to int? It's a little bit upsetting that dbus-monitor will silently omit values if configure couldn't figure out DBUS_INT64_PRINTF_MODIFIER. Maybe it should print "int64 (omitted, see fd.o#19195)"?
Any progress on this? (I'd personally be tempted to say "D-Bus now requires 64-bit integers, and support for them in printf" and see whether anyone reports that this breaks their OS... GLib has the same requirement, now.)
See also Bug #35114. This appears to have been fixed (with wjt's suggestions included) between 1.2.22 and 1.2.24.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.