zaks.anna added inline comments.
================
Comment at: test/Analysis/CFNumber.c:39
+ unsigned char scalar = 0;
+ CFNumberGetValue(x, kCFNumberSInt16Type, &scalar); // expected-warning{{A
CFNumber object that represents a 16-bit integer is used to initialize an 8-bit
integer; 8 bits of the CFNumber value will overwrite adjacent storage}}
+ return scalar;
----------------
NoQ wrote:
> 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.
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.
https://reviews.llvm.org/D25876
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
