[llvm-bugs] [Bug 26640] Unitialized variable usage not checked in some cases

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26640

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|---                         |WONTFIX

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> ---
The general problem of determining whether a variable is used uninitialized is
not computable, so it is fundamental that we will have false negatives in some
cases. Also, as a part of -Wall, this warning cannot be too computationally
expensive, and there are limits to the amount of complexity we will allow to
detect this, and we do not want the warning under -Wall to have false
positives.

Our current choice is to diagnose the following under -Wall:

 -Wuninitialized: diagnose when a use of a variable will *always* read an
uninitialized value (that is, when there is no control flow path leading to
that point that initializes the variable)
 -Wsometimes-uninitialized: diagnose when a branching construct is written in
the source code, and one of its choices creates the situation that
-Wuninitialized diagnoses

Note that neither of these checks has any false positives (under the assumption
that the user didn't write any branching constructs that always actually branch
the same way).


If you want more protection against uninitialized uses, we offer one other flag
(not under -Wall):

 -Wconditional-uninitialized: diagnose when a use of a variable could *ever*
read an uninitialized value (that is, when there exists a control flow path --
although perhaps one that is dynamically impossible -- leading to the use that
does not initialize the variable)

Note that this warning flag has no false negatives (at least, for the kinds of
variables that it checks, and under the assumption that if the address of the
variable escapes the analysis, the variable becomes initialized).


If you want more precise, value- and control-flow-dependent analysis, that can
detect bugs such as yours by reasoning about the value of the 'flag' variable,
you will need a more sophisticated static analyser than the one that powers
this warning. You could try using the Clang Static Analyser -- it should catch
this bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160216/be4c721f/attachment.html>