mitigated Unchecked return value Coverity warnings

[firewave]

No description provided.

[firewave]

@pfultz2 please have a look.

[danmar]

ok so as far as I see these are false positives.. we ignore the return value by intention?

another possible mitigation would be to mark them as false positives in the coverity ui right? however it could mean more work in the long run if we need to mark them as false positives again..

[firewave]

These are not a false positives. The analysis looks at the code and if it sees that the return value is used in most cases it flags it as unintentional and a potential issue. If we would enable the clang-tidy warning about introducing [[nodiscard]] that would probably come up as well.

[danmar]

These are not a false positives. The analysis looks at the code and if it sees that the return value is used in most cases it flags it as unintentional and a potential issue.

well.. from my point of view that ARE false positives. If we ignore the return values by intention then they are false positives. If they are true positives (we unintentionally ignore the result) then you shouldn't add void casts.

I don't classify a finding as false positive or true positive depending on what heuristics the tool use. The heuristic coverity uses is not insane at all. I do feel it could probably detect some genuine bugs also.

[danmar]

I approve this fix..

[firewave]

I will still wait for feedback from @pfultz2 as I have no idea if this was intentional or not.

[orbitcowboy]

I will still wait for feedback from @pfultz2 as I have no idea if this was intentional or not.

I vote to merge this because it is good practice to be explicit. By casting a return value to void, its clear that the return value is ignored in this context.

[firewave]

I vote to merge this because it is good practice to be explicit. By casting a return value to void, its clear that the return value is ignored in this context.

Watch out for more fun in that area soon.