ariccio added a comment. In http://reviews.llvm.org/D17983#370717, @dblaikie wrote:
> Initializations we never expect to use (eg because we have a covered switch > that initializes in all cases, or some slightly complex control flow the > compiler can't see through) hinder our ability to find uses of those with > tools like msan. Too bad... Maybe msan should have a way to specify that you're default initializing a variable, and treat it as if you're not initializing it at all? That said, I'm not sure that I agree with keeping `Potentially uninitialized local pointer variable 'name' used` off (//that's C4703 <https://msdn.microsoft.com/en-us/library/jj851030.aspx>, not C4701 <https://msdn.microsoft.com/en-us/library/1wea5zwe.aspx>//), because uninitialized local pointer bugs are more dangerous (I'm thinking <http://googleprojectzero.blogspot.com/2015/08/one-font-vulnerability-to-rule-them-all_21.html> of write-what-where <http://thesprawl.org/research/ost-introduction-software-exploits-uninit-overflow/> uninitialized pointer vulnerabilities <http://ioctl.ir/index.php/2016/02/13/cve-2016-0040-story-of-uninitialized-pointer/>), and I'd rather crash on a nullptr deref than some undefined behavior. I will drop the `default` cases as @dsanders noted, but should I drop all the local variable inits too? In several cases (which I didn't specifically note) I chose default initialization values that would trigger pre-existing `assert`s if nobody assigned anything else to them. Regarding the 33 warnings I noted, i couldn't tell whether they're obviously false positives, which I think warrants someone other than me carefully looking through it. Some of the warnings are caused by assigning to a variable inside of a loop with a dynamically sized bound; for those, I'd much rather (a) `assert` that the bound is nonzero/loop will be executed at least once, or (b) assign the variable some sentinel value, and then assert it before the variable is actually used. Thoughts? http://reviews.llvm.org/D17983 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
