Completion of error handling

[elfring]

Would you like to add more error handling for return values from functions like the following?

• pthread_mutex_init ⇒ xheap::initialize
• sigaction ⇒ watchpoint::installWatchpoints

[bpowers]

Hi @elfring,

The first one is not an issue - the only way pthread_mutex_init can fail is if you ask for unwindable mutexes.

We probably should check the result of sigaction.

How did you find these issues?

yours, Bobby

[elfring]

The web search interface by GitHub can also be a tool for static source code analysis to some degree.

I suggest to avoid ignorance of return values a bit more. Would you like to detect every error situation as early as possible?

[elfring]

How do you think about to improve static source code analysis also for this software?

[bpowers]

@elfring Can you either share the analysis you are looking at, or explain in more detail what your question is?

[elfring]

Under which circumstances are you going to care for the remaining unchecked function return values?

[bpowers]

@elfring ideally, when I can see the results of a tool showing me that I should care. So for the case of pthread_mutex_*, can your tool (using static analysis) show me that it is even possible for those return values to be non-zero?

Additionally - can your tool ignore pthread_mutex_* functions, and tell me about other missing return values? It isn't that I don't care in general - just that I am skeptical about some of the cases you have brought up (although I did add an assert for the sigaction you mentioned above).

[elfring]

It is easy sometimes to find more update candidates while it can be harder to agree on the complete software solution. On which way would you like to continue?

[bpowers]

@elfring:

1 - Please tell us more about the tool you are running. 2 - Please post the full report of your tools output somewhere, for an example, see Coveralls: https://coveralls.io/builds/4446686/source?filename=mdl.c 3 - Allow us to hide false-positives. 4 - Allow us to re-run the tool when we push new commits to GitHub.

That would be 1000x more useful than you running a tool, once, in private, and opening up a trickle of issues related to code you don't understand deeply. That would turn me into an advocate for your tool!

[elfring]

Some tools should be usable to check calls of functions with a non-void return type. Please choose one for your needs.

[bpowers]

@elfring can you please tell us more about the tool you ran on DoubleTake?

[elfring]

I suggest to reuse the following tools for finding more update candidates depending on your preferences for factors like freedom, licence costs and programming language support.

1. AspectC++
2. Secure Programming Lint
3. Coccinelle
4. Coverity Scan
5. GitHub

[bpowers]

Hi @elfring - are your responses to my questions completely automated?

[elfring]

No. - I admit that I dare to repeat variations of previous answers for recurring issues.