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
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. Ther
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
Date: Sun Oct 30 18:36:47 2011 +0100
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
> 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
