[llvm-bugs] [Bug 47597] New: False positive coming when -isystem is used

[via llvm-bugs]

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

            Bug ID: 47597
           Summary: False positive coming when -isystem is used
           Product: clang
           Version: 10.0
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
          Assignee: dcoughlin at apple.com
          Reporter: cassio.neri at gmail.com
                CC: dcoughlin at apple.com, llvm-bugs at lists.llvm.org

Consider:

// file: leak.cpp
#include <benchmark/benchmark.h> // Google benchmark library

void foo(benchmark::State& state);

int main() {
  benchmark::RegisterBenchmark("foo", foo);
}

$ scan-build clang++ -isystem <path-to-benchmark> -c leak.cpp
scan-build: Using '/usr/bin/clang-8' for static analysis
In file included from leak.cpp:1:
path-to-benchmark/benchmark/benchmark.h:974:3: warning: Potential memory leak
  return internal::RegisterBenchmarkInternal(
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Replacing -isystem with -I silences the warning. If anything, I'd expect
-isystem to issue less warnings than -I and not the other way round. I've
managed to pinpoint the issue (imitating benchmark) in this SSCCE:

// file: leak.hpp
#pragma GCC system_header // removing this line silences the warning

void foo(int*);

void bar() {
  foo(new int);
}

// file: leak.cpp
#include "leak.hpp"

int main() {
  bar();
}

$ scan-build clang++ -c leak.cpp
scan-build: Using '/usr/bin/clang-8' for static analysis
In file included from leak_tmp.cxx:1:
./leak.hpp:7:1: warning: Potential memory leak
}
^

As said above, I'd expect less warnings with the #pragma than without it.
Actually, in this case, I would prefer no warning at all. It is possible, after
all, that foo frees the memory.

FWIW:
1) '-disable-checker unix.Malloc' does not silence the warning.
2) Same behavior with clang-10.

-- 
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/20200921/29955ea4/attachment.html>