For better code quality, we should be able to build dbus with clang so that its better (or just different) compiler warnings can point out bad code. As a first step towards that, I've been building it with: -Wno-error=cast-align -Wno-error=pointer-sign -Wno-error=unused-const-variable -Wno-error=tautological-compare of which pointer-sign is Bug #15522 (and I'm not quite sure why configure isn't detecting that suppression as supported already).
Created attachment 113693 [details] [review] tests: reassure clang that oom() does in fact not return --- gcc can tell that g_error is already noreturn, but clang can't.
Created attachment 113694 [details] [review] marshalling tests: fix an incorrect use of memcmp --- We intended to memcmp sizeof(literal) bytes but were actually comparing 1 byte. Oops. (The tests still pass with this fixed, though.)
Comment on attachment 113694 [details] [review] marshalling tests: fix an incorrect use of memcmp looks good
Comment on attachment 113693 [details] [review] tests: reassure clang that oom() does in fact not return Review of attachment 113693 [details] [review]: ----------------------------------------------------------------- looks good
Patches applied, thanks. I'll leave this open, because there are still obvious clang warnings.
(In reply to Simon McVittie from comment #0) > -Wno-error=cast-align That's essentially Bug #10599 so I'm treating it as somewhat out-of-scope for this bug (although it would be good to suppress the warning until then). > -Wno-error=pointer-sign This is Bug #15522; similar. > -Wno-error=unused-const-variable This is a new insight from clang; gcc doesn't notice. We probably just need more #ifndef TESTS or whatever. > -Wno-error=tautological-compare clang is making one of our enums unsigned, where gcc makes it signed. I think we might also be abusing the relevant enum to take an out-of-range value (not allowed in Standard C) which ought to be fixed one day anyway.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/122.
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.