Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Clang analyzer run #4051

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jan 21, 2017
Merged

Clang analyzer run #4051

merged 3 commits into from
Jan 21, 2017

Conversation

tiennou
Copy link
Contributor

@tiennou tiennou commented Dec 29, 2016

This is a few low-hanging fruits from using Xcode "Analyze" against libgit2.

Current master has 85 of those, this one is 81, and I managed to get it down to 64 by having more fine-grained control over GITERR_CHECK_ALLOC helps. If you feel that's a worthy goal, I can make another PR with those changes.

There are a few harder things which I can't tell if they're false-positives or not.

@ethomson
Copy link
Member

Thanks, @tiennou !

@ethomson ethomson merged commit 185fe9c into libgit2:master Jan 21, 2017
@tiennou
Copy link
Contributor Author

tiennou commented Jan 22, 2017

As a side note, after silencing the warnings about alloc failures and some other things, I still see 47 analyzer reports.

Also, I have a question : the analyzer is "confused" by the differing stance we can have w.r.t to negative/not-zero error checks. Since I already derailed this PR with a discussion about error handling, I'll complete my tour with this one : is there a current, recommended idiom for int error returns, or is switching all instances to != 0 a goal worthy of being merged ?

@ethomson
Copy link
Member

Also, I have a question : the analyzer is "confused" by the differing stance we can have w.r.t to negative/not-zero error checks. Since I already derailed this PR with a discussion about error handling, I'll complete my tour with this one : is there a current, recommended idiom for int error returns, or is switching all instances to != 0 a goal worthy of being merged ?

Yes to both of your questions. 😝

The current, recommended idiom is:

if (error < 0)

Which - is pretty deficient, as you point out, and as we've had lingering at #2716. The new recommended idiom should probably be:

if (error)

Which is more succinct, readable and handles positive exit codes.

That's my opinion, anyway, but I haven't led the charge to make a fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants