> 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
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 lon
> > 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
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 per
