[cfe-users] Is there a way to make clang warn on this code?

Quentin Colombet qcolombet at apple.com
Mon Mar 17 10:02:53 PDT 2014

Thanks all!

On Mar 17, 2014, at 9:40 AM, Jordan Rose <jordan_rose at apple.com> wrote:

> On Mar 15, 2014, at 19:01 , David Blaikie <dblaikie at gmail.com> wrote:
>> On Fri, Mar 14, 2014 at 7:05 PM, Richard Trieu <rtrieu at google.com> wrote:
>>> Quentin,
>>> Clang does not have a warning for uninitialized fields in class methods.
>>> I've looked before to add a warning to flag any unused fields at the end of
>>> the a constructor.  However, there were good reasons to have uninitialized
>>> fields, such as having an Init() method later that initializes the fields,
>>> or a guard variable to protect against uninitialized use.  Also,
>>> -Wuninitialized typically warns on the use of an uninitialized variable, not
>>> the mere presence of one.
>>> The other idea is to do cross method analysis, either using the control flow
>>> of a program to determine which methods are used in which order, or testing
>>> methods against constructors.  Such an analysis would likely be too
>>> expensive, and would be more suited for static analysis.
>> We already have at least one cross-method analysis which could
>> actually be used as the basis for the warning under discussion here:
>> -Wunused-member-variable. This warning only fires if there are no
>> friends and a private member in a situation where all member functions
>> are defined in one translation unit.  So we could use this to show
>> that there's no initialization of the variable anywhere, but there are
>> uses of it. (essentially the same as -Wunused-member-variable, except
>> allow reads as well)
> The analyzer also catches the particular case in your stripped-down test file, and should do so on real code as long as it's all visible in one translation unit. It'd be a lot harder to make this a cross-TU analysis, of course.
The actual problem is cross-TU.
Is there a plan or a way to run the analyzer on several TU?


> Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20140317/feebe982/attachment.html>

More information about the cfe-users mailing list