Re: [AVaRICE-user] Bug in AVaRICE 2.13

[Marian B. <mar...@ov...>]

Dear Jörg Wunsch,

thanks for the quick reply.

> See bug report #24 (filed just recently)

Actually I had a look into the bug tracker and before writing the email and
couldn't find it. I also wanted to add a bug, but I really don't want to create
an account on SourceForge. Every time I click on something there a huge "we
value your privacy" banner is jumping in my face. And I only need to click on
"More Options" to see the provide that this is a lie...

My point is: SourceForge.net is a platform that really scares me away from an
open source project, no matter how cool it is. Other coders and potential
contributors may feel the same way about it. Maybe with teahub.io a good
alternative will (hopefully) emerge some day in the (hopefully) not too distant
future. Maybe that is worth for AVaRICE to look into, when it becomes available?

> Changing whitespace just for the purpose of changing it is generally
> not a good idea.  It potentially obfuscates real code changes later on.

(Sorry for writing a quite emotional rant about it, but inconsistent indent is
one of my pet peeves:)

I cannot disagree more on that. I see a VCS log as a tool to tweak the code -
not writing code as a tool to tweak the VCS log.

Inconsistent coding style makes reading and understanding the code harder. It
increases the barrier to get other people to contribute code and identifying
bugs harder. E.g. the CVE-2013-1266 (a.k.a. goto fail) [1] would most likely be
detected sooner when correct code indentation would have been used. This even
lead to the new "-Wmisleading-indentation" warning option in GCC [2]. So
getting code indentation consistent (no matter if you prefer tabs, spaces or
smart tabs) has a huge impact on code quality, even if this only changes white
space.

Kind regards,
Marian Buschsieweke

[1]: https://nvd.nist.gov/vuln/detail/CVE-2014-1266
[2]:
https://developers.redhat.com/blog/2016/02/26/gcc-6-wmisleading-indentation-vs-goto-fail/

-------------------------------------------------------------
M.Sc. Marian Buschsieweke
Dept. Communication and Networked Systems (ComSys)
Institute for Intelligent Cooperating Systems (IKS)
Otto-von-Guericke-University of Magdeburg
Universitätsplatz 2, Building 29, Room 314
39106 Magdeburg
Germany

http://www.comsys.ovgu.de/Team/Marian+Buschsieweke.html
Tel.: +49 - 391 - 67 - 52673
Fax:  +49 - 391 - 67 - 41161

-------------------------------------------------------------

On Tue, 10 Jul 2018 12:21:58 +0200
Joerg Wunsch <j...@ur...> wrote:

> As Marian Buschsieweke wrote:
> 
> > the attached patch fixes an incorrect return statement: Apparently old GCC
> > versions implicitly casted "false" to "NULL", which no longer is the case. So
> > the "return false;" statement in jtagrw.cc:134 in function 
> > 
> > uchar *jtag1::jtagRead(unsigned long addr, unsigned int numBytes)
> > 
> > should be replaced by "return NULL;"  
> 
> See bug report #24 (filed just recently)
> 
> > Also, there is a lot of inconsistent use of tabs and spaces for indent. Maybe
> > running astyle, uncrustify, or whatever of the code would be a good idea? ;-)  
> 
> Changing whitespace just for the purpose of changing it is generally
> not a good idea.  It potentially obfuscates real code changes later on.
> 
> That doesn't mean maintaining a consistent style is a bad idea, but I
> wouldn't want to commit changes just for that.