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
New package for Windows is available for download on my website
www.freddiechopin.info
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
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/140
-- gerrit
commit 8cb99c45f508b20fbac9aa9649374b774cb647d8
Author: Øyvind Harboe oyvind.har...@zylin.com
Date: Sun Oct 30
openocd-development-boun...@lists.berlios.de wrote:
Mathias K. wrote:
can you remove the magic incomplete number too?
In this case the 1533d9d. This number is useless in the subject:
I disagree. This is an abbreviated commit hash, which identifies the
commit that was pushed. There's also
Mathias K. wrote:
can you remove the magic incomplete number too?
In this case the 1533d9d. This number is useless in the subject:
I disagree. This is an abbreviated commit hash, which identifies the
commit that was pushed. There's also Gerrit's identifiers, but losing
the commit
