> 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
On Sat, Oct 29, 2011 at 10:56 AM, wrote:
> This is an automated email from Gerrit.
>
> ?yvind Harboe (oyvindhar...@gmail.com) just uploaded a new patch set to
> Gerrit, which you can find at http://openocd.zylin.com/134
>
> -- gerrit
>
> commit 620ba7e6cd57c951fafa0f1ffab2db102fe2a60f
> Author: Ø
