[llvm-bugs] [Bug 34521] New: Uninitialized Reads Cannot Be Suppressed On A Per-Field Level

[via llvm-bugs]

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

            Bug ID: 34521
           Summary: Uninitialized Reads Cannot Be Suppressed On A
                    Per-Field Level
           Product: clang
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: russ at eatnumber1.com
                CC: llvm-bugs at lists.llvm.org

I have a type which is by-design intended to behave like a primitive type. E.g.

  class MyInt {
    int i_;
   public:
    int get() { return i_; }
    void assign(int i) { i_ = i; )
  };

ClangTidy marks the read of i_ in get() as an uninitialized read (which it is)
by emitting clang-analyzer-core.CallAndMessage; but since MyInt is intended to
work like a primitive type, it is intended that the following code is UB:

  MyInt i;
  i.get();

I could simply add a // NOLINT(clang-analyzer-core.CallAndMessage) suppression
to the read of i_, but future changes to the class which introduce additional
reads of i_ will need to duplicate the suppression. Ideally, there would be a
way to suppress the warning on the declaration of i_ such that it will not emit
the warning on any reads of the field. Even better, it would be ideal to be
able to mark MyInt as a "primitive-like" type so the CallAndMessage analyzer
would warn on uninitialized reads of the MyInt type.

-- 
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/20170907/3b6e68bb/attachment.html>