danielmarjamaki added a comment. In http://reviews.llvm.org/D10634#217441, @soumitra wrote:
> In http://reviews.llvm.org/D10634#217438, @danielmarjamaki wrote: > > > In http://reviews.llvm.org/D10634#217433, @soumitra wrote: > > > > > In http://reviews.llvm.org/D10634#213835, @zaks.anna wrote: > > > > > > > I am leaning toward allowing explicit assignments to "-1", like in this > > > > case: "unsigned int j = -1". The tool is much more usable if there are > > > > few false positives. > > > > > > > > > This is exactly what I started off with, albeit with a plain 'char' > > > instead of 'unsigned int'. We were hitting a runtime issue while porting > > > a large piece of software to AArch64 since the "signedness" of plain char > > > changes across x86 and AArch64, and a negative value was used as a > > > initializer. > > > > > > I am also still skeptic about this. Ideally there should only be warnings > > when there is a mistake. > > > > In your example code you showed previously there were portability problems > > because the signedness changed. A warning for that is ok in my opinion. > > > > If the code says 'unsigned int j = -1;' then there is no such portability > > problem. > > > Ah! Now I get it!! > > So, the case I have is assignment of a negative value to a 'plain char'. Is > there a way I can check for a 'plain char' in the checker as against a > generic 'unsigned' integral variable? Great. I don't know how off the top of my head. But it should be possible. http://reviews.llvm.org/D10634 _______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
