[llvm-bugs] [Bug 26902] New: static analyzer false positives due to pointer cast

[via llvm-bugs]

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

            Bug ID: 26902
           Summary: static analyzer false positives due to pointer cast
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: nlewycky at google.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

This testcase is plain C code:

  typedef struct Packet_s {
    unsigned char lefthanded;
  } Packet;

  int test(const unsigned char *payload) {
    Packet *packet = (Packet*)payload;
    if (packet->lefthanded)
     return 1;
   return 0;
  }

I'm running 'clang_tidy -checks=* tc.c --' to exercise the static analyzer. The
first statement warning is a false positive:

/usr/local/google/home/nlewycky/tc.c:6:20: warning: Casting a non-structure
type to a structure type and accessing a field can lead to memory access errors
or data corruption [clang-analyzer-alpha.core.CastToStruct]
  Packet *packet = (Packet*)payload;
                   ^

That's true in the general case, but not in the specific case of a struct with
a single unsigned char. This isn't even an ABI guarantee, the standard, I
think, promises that this is safe.

Since it doesn't understand 'packet', it treats the conditional on the member
in a really bad way:

/usr/local/google/home/nlewycky/tc.c:8:12: warning: This statement is never
executed [clang-analyzer-alpha.deadcode.UnreachableCode]
    return 1;
           ^
/usr/local/google/home/nlewycky/tc.c:8:12: note: This statement is never
executed
    return 1;
           ^
/usr/local/google/home/nlewycky/tc.c:9:10: warning: This statement is never
executed [clang-analyzer-alpha.deadcode.UnreachableCode]
  return 0;
         ^
/usr/local/google/home/nlewycky/tc.c:9:10: note: This statement is never
executed
  return 0;
         ^

I don't really understand the chain of logic that led to both of these reports.
It would make sense to treat 'packet' as containing opaque data after a bad
cast, rather than toxic.

-- 
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/20160310/ecd7e6a6/attachment.html>