[PATCH] D17983: Eliminate many benign instances of "potentially uninitialized local variable" warnings
Alexander Riccio via cfe-commits
cfe-commits at lists.llvm.org
Wed Mar 9 11:58:42 PST 2016
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
More information about the cfe-commits
mailing list