Completion of error handling #1

Closed
elfring opened this Issue Mar 13, 2016 · 12 comments

Projects

None yet

3 participants

@elfring
elfring commented Mar 13, 2016

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

@ralight
Contributor
ralight commented Mar 13, 2016

The malloc calls - yes definitely.

The call to fwrite - there's not a lot that can be done if it fails so there isn't much point checking it.

@ralight ralight added a commit that referenced this issue Mar 13, 2016
@ralight ralight Handle some unchecked malloc() calls. Closes #1.
Thanks to Markus Elfring.
35c4d3d
@ralight
Contributor
ralight commented Mar 13, 2016

Closed in 35c4d3d

@ralight ralight closed this Mar 13, 2016
@elfring
elfring commented Mar 13, 2016

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

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

@ralight
Contributor
ralight commented Mar 13, 2016

In this case ignoring the return value of fwrite is only as "bad" as ignoring the return value from printf.

The project is run through Coverity Scan on a fairly regular basis.

@elfring
elfring commented Mar 13, 2016

I wonder still how many return values are ignored (or "overlooked") in the provided source files at the moment.
Would you like to care also for return codes from functions of the POSIX thread programming interface (for example)?

@ralight
Contributor
ralight commented Mar 14, 2016

Thanks for your input, but it is not helpful to just make speculative comments like this. If you have specific bug reports to make, please do open more reports.

@elfring
elfring commented Mar 14, 2016

…, but it is not helpful to just make speculative comments like this.

Does your use of the tool "Coverity" point open issues out around Pthread functions?

@ralight
Contributor
ralight commented Mar 14, 2016

Yes, coverity points out issues with the use of pthreads.

I'm sure you are well intentioned, but the manner in which you approach issues here on github in lots of projects is not very ameanable. I would suggest that you do not reply to every comment with a vague question, instead if you can offer specific help I would be happy to receive it.

Please do not comment on this issue again, the specific issues you highlighted have been fixed. If you believe there are other issues, please open a new report.

@elfring
elfring commented Mar 14, 2016

Yes, coverity points out issues with the use of pthreads.

I find it unclear for me which implementation details are in the waiting queue for further considerations already because of source code analysis reports by this tool.

If you believe there are other issues, please open a new report.

Do you really want a separate bug report for almost every return value that is ignored so far?

@kartben
kartben commented Mar 14, 2016

I think what would be really helpful would be pull requests, that the
community would be able to review depending on the tradeoff between
improving actually robustness, or just changing the code just in order to
make some code analysis tool happy.
If you can demonstrate the value of the changes via actual code changes, I
think it'll be much more productive and valuable than endlessly commenting
on bugs. It would also help to indicate what actual problem you are trying
to solve for each specific pull request.

Le lun. 14 mars 2016 21:05, Markus Elfring notifications@github.com a
écrit :

Yes, coverity points out issues with the use of pthreads.

I find it unclear for me which implementation details are in the waiting
queue for further considerations already because of source code analysis
reports by this tool.

If you believe there are other issues, please open a new report.

Do you really want a separate bug report for almost every return value
that is ignored so far?


Reply to this email directly or view it on GitHub
#1 (comment).

@ralight
Contributor
ralight commented Mar 14, 2016

There are two outstanding issues found by coverity scan. They are viewable by anyone.

What I would like is specific bug requests, not vague questions. I do not want a bug report for each return value that is ignored, I would like considered bug reports that include an analysis of why that particular situation is a problem.

You seem to assume that there hasn't been any consideration of return values, this isn't the case. In a very few cases there may be a bug, but just questioning all possible return codes is not constructive.

@elfring
elfring commented Mar 18, 2016

Some update candidates were pointed out by a script in the semantic patch language (Coccinelle).
Do you find the attached excerpt from an analysis result interesting?
unstored_return_values-POSIX-example-20160318.zip

@ralight ralight added this to the 1.4.9 milestone May 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment