This is an archive of the discontinued LLVM Phabricator instance.

[analyzer] Report CFNumberGetValue API misuse
ClosedPublic

Authored by zaks.anna on Oct 21 2016, 11:53 AM.

Details

Summary

This patch contains 2 improvements to the CFNumber checker:

  • Checking of CFNumberGetValue misuse.
  • Treating all CFNumber API misuse errors as non-fatal. (Previously we treated errors that could cause uninitialized memory as syncs and the truncation errors as non-fatal.)

This implements a subset of functionality from https://reviews.llvm.org/D17954.

Diff Detail

Repository
rL LLVM

Event Timeline

zaks.anna updated this revision to Diff 75456.Oct 21 2016, 11:53 AM
zaks.anna retitled this revision from to [analyzer] Report CFNumberGetValue API misuse.
zaks.anna updated this object.
zaks.anna added reviewers: dcoughlin, NoQ.
zaks.anna added subscribers: cfe-commits, rgov.
dcoughlin added inline comments.Oct 21 2016, 1:13 PM
test/Analysis/CFNumber.c
39 ↗(On Diff #75456)

I feel like this diagnostic is not dire enough. The problem is not that the bits will be lost -- but rather that they will be overwritten on top of something else!

How about something like "The remaining 8 bits will overwrite adjacent storage."?

45 ↗(On Diff #75456)

Some grammar/style nits. (I realize these also hold for the pre-existing checks):

  • There should be a dash between the number and 'bit'. That is, it should be "16-bit" and "8-bit".
  • It is generally considered bad style to start a sentence with a number that is not written out (except for dates). How about starting the second sentence with "The remaining 8 bits ..."?
zaks.anna updated this revision to Diff 75488.Oct 21 2016, 2:38 PM

Address comments from Devin.

dcoughlin accepted this revision.Oct 25 2016, 11:23 AM
dcoughlin edited edge metadata.
This revision is now accepted and ready to land.Oct 25 2016, 11:23 AM
NoQ added inline comments.Oct 25 2016, 11:54 AM
test/Analysis/CFNumber.c
39 ↗(On Diff #75488)

We're not sure from this code if the CFNumber object x actually represents a 16-bit integer, or somebody just misplaced the kCFNumberSInt16Type thing. I think the warning message could be made more precise in this sence, but i'm not good at coming up with warning messages.

Hmm, there could actually be a separate check for detecting inconsistent type specifiers used for accessing the same CFNumber object.

zaks.anna added inline comments.Oct 25 2016, 3:47 PM
test/Analysis/CFNumber.c
39 ↗(On Diff #75488)

I see your point. Looks like we'd need to modify both first part of the sentence and the second to address this concern. We could do something like "A CFNumber object treated as if it represents a 16-bit integer is used to initialize an 8-bit integer; 8 bits of the CFNumber value or the adjacent storage will overwrite adjacent storage of the integer".

Though this is more correct, I do not think it's worth the new language complexity. Also, the warning message is already quite long.

This revision was automatically updated to reflect the committed changes.