Clang static analyzer report

[Sergey Stepanov]

I've run clang static analisys on master branch of geda-gaf git source tree (after `./configure`-ing):

$ scan-build -o $HOME/reports make -j4
scan-build: 81 bugs found.
scan-build: Run 'scan-view 2015-10-01-235503-11998-1' to examine bug reports.

archive with full report is attached. unpack it, and open index.html with you favorite web-browser.

I run static analisys with every checking option enabled to get 1346 bugs found:

$ scan-build -o $HOME/reports -analyze-headers -enable-checker alpha -enable-checker core -enable-checker security -enable-checker unix make -j4

Archive with full report is a bit longer (~2.5Mb), so I desided not to attach it, but I can do it if you wish.

[Vladimir Zhbanov (vzhbanov)]

Hi, Sergey.

I've merged your branch into master and have an only question
related to it:

Does the fixed block in commit 4cc1c7c do anything? Have you seen
anything different on the screen or in a document exported to PDF
or whatever that differs with what we have now? If not, it would
probably better to get rid of it.

The second question is about this bug. Do you consider it worth to
have it opened here, which might continue forever while we are
writing code? Wouldn't it be better to just fix the bugs you see
in the master branch?

Thank you for your work,
  Vladimir

[Sergey Stepanov (no-such-process)]

  Hello

> I've merged your branch into master

It was too premature. I planned to put fixups in that branch, so you or other maintainer can review them and cherry-pick particular commits that worth it. You see, I, as a new developer, have to spend a plenty of time to dive into sources, so I concidered that fighting these simple bugs would be a good start. Anyway, done is done, thank you.

> Does the fixed block in commit 4cc1c7c do anything?

I thought this commit will fix one annoying bug I see every day, but I failed.

> Do you consider it worth to have it opened here, which might continue forever while we are writing code?

Well, why not? There is the receipe to collect bugs, the thorough list of automatically found bugs. Maybe they are deals with already registered bugs. (Or do you mean, that this bugreport should be opened in other LP project?)

> Wouldn't it be better to just fix the bugs you see in the master branch?

Maybe yes, maybe no, I don't know. You merged the obvious and trivial pathes, but others are not so trivial, and may require more work (or rework). So, this branch was a sandbox for my patches.

[Vladimir Zhbanov (vzhbanov)]

On Thu, Oct 08, 2015 at 06:37:46PM -0000, Sergey Stepanov wrote:
> Hello
>
> > I've merged your branch into master
>
> It was too premature. I planned to put fixups in that branch, so you or
> other maintainer can review them and cherry-pick particular commits that
> worth it. You see, I, as a new developer, have to spend a plenty of time
> to dive into sources, so I concidered that fighting these simple bugs
> would be a good start. Anyway, done is done, thank you.
I don't think so. I reviewed them and merged one by one. Or do you think
I had to wait until you fix all the several hundreds of the declared
bugs? :-P I haven't removed the branch, so please continue your work.
>
> > Does the fixed block in commit 4cc1c7c do anything?
>
> I thought this commit will fix one annoying bug I see every day, but I
> failed.
>
> > Do you consider it worth to have it opened here, which might continue
> forever while we are writing code?
>
> Well, why not? There is the receipe to collect bugs, the thorough list
> of automatically found bugs. Maybe they are deals with already
> registered bugs. (Or do you mean, that this bugreport should be opened
> in other LP project?)
No, I don't :) However, this is just a routine work that devs do if they
want to. AFAIUI, bugtrackers are more about user annoying bugs and
wishlists. And one of their goals is to show users the progress we have.
>
> > Wouldn't it be better to just fix the bugs you see in the master
> branch?
>
> Maybe yes, maybe no, I don't know. You merged the obvious and trivial
> pathes, but others are not so trivial, and may require more work (or
> rework). So, this branch was a sandbox for my patches.

OK, thanks,
  Vladimir