Discuss: lint warnings from splint

[gbonnema]

Hi Alessandro,

I ran splint (a version of lint) on some of the code and the outcome is a lot of warnings. I did the same with gcc -Wall and receive a massive amount of warnings as well. It's old code, so to be expected.

I also checked out more structural issues. There is a lot of global sharing going around and it is often unclear what a variable is for or what a function does exactly. Also, some functions are too big for their own good. I fear for cohesion of code per function.

I concluded from the readme, that you don't want to get too heavily involved, so the question is what should we do with this mess? Or should we do anything at all?

Kind regards, Guus.

[amagnasco]

Hi Guus,

Let's do this. This is the kind of code that it's fun to debug and fix, but then people get bored and leave. No judgment whatsoever. This is exactly why I put in Github; there's 0 pressure. If someone wants to fix it they can, I'll be here.

I'm kind of tied up for time at the moment, so I can't be actively looking for bugs. That hopefully changes soon. I'll add all of the old bug trackers as current issues.

You can run point on finding new issues, I'll verify the problem on my end. We can post lint and valgrind messages as well. We decide on a plan of attack, base changes off of the the development branch as we've been doing. We test each solution individually. When devel has a couple of things in it, we can test them all together, thoroughly. If it works, we jump to the next release version to signify new team. Change from xwpe-alpha to xwpe-git.

Best, Alessandro

On May 28, 2017 9:24:32 AM EDT, Guus notifications@github.com wrote:

Hi Alessandro,

I ran splint (a version of lint) on some of the code and the outcome is a lot of warnings. I did the same with gcc -Wall and receive a massive amount of warnings as well. It's old code, so to be expected.

I also checked out more structural issues. There is a lot of global sharing going around and it is often unclear what a variable is for or what a function does exactly. Also, some functions are too big for their own good. I fear for cohesion of code per function.

I concluded from the readme, that you don't want to get too heavily involved, so the question is what should we do with this mess? Or should we do anything at all?

Kind regards, Guus.

-- Alessandro G. Magnasco Currently at New York City / Development Initiatives & Technical Assistance /

Sent from my pocket computer

[gbonnema]

My involvement The time I spend, like yours, varies. At this moment I am looking to improve my understanding of C and to do some real improvements to xwpe. Should I get a job (desired, but unlikely) I will be able to spend less time.

My approach The biggest issue I see at the moment is that it is difficult to understand the program. Each pull request should bring us closer to a better understanding. I will suggest changes to improve readability. Once we understand the intention better we should be able to get real improvements.

My suggestion is to make no functional changes until we improved the program maintainability. I see a few ways to do that:

1. Removing warnings we find through gcc -Wall or splint.
2. Refactor variables and functions in naming so they become more understandable
3. Correct bugs if we happen to find them (valgrind is useful).

All these without functional changes. The next stage would be to do some real refactoring. Some of the functions seem to carry the weight of the world ..... But only after we understand what is going on.

If, you would be my consience that would be great. Am I changing the right things? am I changing them in the right way? Be critical: that can only improve things.

Once you have more time, we can renegotiate tasks.

[amagnasco]

Perfect, I'm glad we're on the same page on this. I've been viewing the program in the same way.

First release from devel branch should address only warning and error messages, finding the memory leaks, clarifying the defines, and documentation. After that release, then we can work on rewriting the functions.

I added all the old bugs to the issue list, and I classified them into projects and labels. I also made a milestone for first release of the devel branch. I think you would find it helpful to look through some of the old documentation and mailing list posts, to understand the intent of both the original and alpha projects.

What I'm not sure whether to take comfort in, or not, is that this approach is exactly in line with what the xwpe-alpha project attempted to do. I believe that having the code on Github, with a global collaborative reach, we will be able to overcome the problems faced by the alpha team.

Best, Alessandro

On May 29, 2017 7:34:52 AM EDT, Guus notifications@github.com wrote:

My involvement The time I spend, like yours, varies. At this moment I am looking to improve my understanding of C and to do some real improvements to xwpe. Should I get a job (desired, but unlikely) I will be able to spend less time.

My approach The biggest issue I see at the moment is that it is difficult to understand the program. Each pull request should bring us closer to a better understanding. I will suggest changes to improve readability. Once we understand the intention better we should be able to get real improvements.

My suggestion is to make no functional changes until we improved the program maintainability. I see a few ways to do that:

1. Removing warnings we find through gcc -Wall or splint.
2. Refactor variables and functions in naming so they become more understandable
3. Correct bugs if we happen to find them (valgrind is useful).

All these without functional changes. The next stage would be to do some real refactoring. Some of the functions seem to carry the weight of the world ..... But only after we understand what is going on.

If, you would be my consience that would be great. Am I changing the right things? am I changing them in the right way? Be critical: that can only improve things.

Once you have more time, we can renegotiate tasks.

-- Alessandro G. Magnasco Currently at New York City / Development Initiatives & Technical Assistance /

Sent from my pocket computer