if we start tweaking perfectly good code and adding nonsense checks
just to get a clean scan-build output, I think that's a step
backwards in terms of code quality.
Yes, I agree. I'm not at all fond of throwing assert() at the clang
warnings.
+1 from me aswell.
Spen
There are a couple of topics mixed into this thread:
1. clang sometimes gives false positives. Here the code is usually so
complex that I can understand that clang and programmers have
trouble following the code. The best way would be to refactor the
code to be simpler, in one case I split a long
In this case, the warning is probably bogus (I'll have to check the
scan-build output but having problems logging in to jenkins). Unfortunately,
the fix is, too. There's no point in adding an assert to check for the value
of a variable when that value has no possible bearing on the program
Andreas Fritiofson wrote:
clang: fix warning by adding assert that shows that a variable is used
..
+ assert(e == JIM_OK);
+
..
I'm not very fond of the idea of merging patches with the sole
purpose of fixing scan-build false positives.
+1
if we start tweaking perfectly
