[th/sd-event-assert-return] Avoid side effects for assert_return() resolving sd-event#13250
[th/sd-event-assert-return] Avoid side effects for assert_return() resolving sd-event#13250thom311 wants to merge 2 commits intosystemd:masterfrom
Conversation
…solve(e), -ENOPKG)" Coverity thinks that this is not right: CID 202431 (systemd#1 of 1): Side effect in assertion (ASSERT_SIDE_EFFECT) assignment_where_comparison_intended: Assignment e = event_resolve(e) has a side effect. This code will work differently in a non-debug build. And that's correct: we must always resolve SD_EVENT_DEFAULT, regardless of whether assertions are enabled.
…()) and event_resolve() The checks are always the same. Add and use a macro.
|
Hm, it seems Also, |
|
This seems related: https://community.synopsys.com/s/question/0D534000046Yuzb/suppressing-assertsideeffect-for-functions-that-allow-for-sideeffects We have actually very few Coverity warnings related to |
|
We have made attempts in the past to teach coverity that I'd much rather teach coverity that assert_se is OK... |
2 participants
Coverity warns about this (in NetworkManager's fork of the code), and I think it's right to warn.
Even if it may be a non-issue, False-Positive warnings are still cumbersome because they keep attracting attention.