[llvm-bugs] [Bug 43364] New: [Umbrella] Pointer cast representation problems.

[via llvm-bugs]

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

            Bug ID: 43364
           Summary: [Umbrella] Pointer cast representation problems.
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
          Assignee: dcoughlin at apple.com
          Reporter: noqnoqneo at gmail.com
                CC: dcoughlin at apple.com, llvm-bugs at lists.llvm.org

An umbrella bug for figuring out how to fix our representation of pointer
casts. The main problem with the current representation is that there are
multiple ways of representing the same pointer, however there's no canonical
way of representing a pointer, so different parts of the Analyzer are doing
this differently and only accidentally work together more or less nicely.

Here are a few examples of how they don't really work together nicely:


(1) In http://lists.llvm.org/pipermail/cfe-dev/2019-September/063308.html we
have two different symbolic values for the same actual pointer value, which
wear different constraints after dereferencing:

    reg_$1<int Element{SymRegion{reg_$0<const Item * items>},0
S64b,Item}->xxs>:  { [-2147483648, 0] }
    reg_$2<int SymRegion{reg_$0<const Item * items>}->xxs>:  { [1, 2147483647]
}


(2) Here's another example that's a bit more controversial due to strict
aliasing violation, but still problematic and slightly more obvious:

  typedef struct {
    int RetCode;
  } A;

  typedef struct {
    int RetCode;
  } B;

  int blah(A *param, int *x) {
    if (param->RetCode != 0)  // reg_$1<SymRegion{reg_$0<param>}->RetCode>
      return ((B *) param)->RetCode; // reg_$2{element{B, 0 S32b,
SymRegion{reg_$0<param>}->RetCore}
    *x = 1;
    return 0;
  }

  int foo(A* param) {
    int x;
    if (blah(param, &x) != 0) {
        return 0;
    }
    return x; // false positive: "returning garbage value".
  }

Here we have in the following:

  param->RetCode:  reg_$1<SymRegion{reg_$0<param>}->RetCode>
  ((B *) param)->RetCode:  reg_$2{element{B, 0 S32b,
SymRegion{reg_$0<param>}->RetCore}


(3) The following bugs of this kind are already fixed in a non-principled
manner:

  https://reviews.llvm.org/D38797
  https://reviews.llvm.org/D46224
  https://reviews.llvm.org/D46415
  https://reviews.llvm.org/D51191
  https://reviews.llvm.org/D52189
  https://reviews.llvm.org/D55875


(4) This is also a piece of technical debt that causes annoyance when writing
new code:

  https://reviews.llvm.org/D40939
  https://reviews.llvm.org/D41250
  https://reviews.llvm.org/D67079#inline-602514

-- 
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/20190919/acc8dfd5/attachment.html>