NagyDonat wrote:
These reports are definitely FPs caused by buggy number handling, so it would
be good to suppress them.
I was planning to rewrite both `alpha.security.ReturnPtrRange` and
`alpha.unix.cstring.OutOfBounds` to rely on the "backend" prototyped within
ArrayBoundV2 instead of the c
steakhal wrote:
In this PR, we decided to suppress some reports.
It turns out the `alpha.security.ReturnPtrRange` would overtake some the
suppressed reports and issue a diagnostic itself.
Here is an example:
https://compiler-explorer.com/z/P9bGTjv5W
```c++
const char *unwindTerminator(const char
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/81034
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
> [...] we should strive to handle comparison evaluation more uniformly and
> preferably behind the API barrier of the constraint manager.
Actually this commit is a step towards the opposite direction -- it adds some
tricky workaround logic to one particular checker (and not t
https://github.com/gamesh411 approved this pull request.
https://github.com/llvm/llvm-project/pull/81034
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
gamesh411 wrote:
I checked many false positives, even those that were not FP at first sight; I
think we can live without them.
I also agree that we should strive to handle comparison evaluation more
uniformly and preferably behind the API barrier of the constraint manager.
LGTM
https://github.
NagyDonat wrote:
The main effect of this commit is that it eliminates ~300-400 ArrayBoundV2
reports. I didn't review each of them, but I checked dozens of them and those
were all "Out of bound access to memory after the end of the region" false
positives that tried to access something at index
NagyDonat wrote:
I did an open source evaluation of this commit and there are surprisingly many
changes:
| Project | With this commit | Without this commit |
|-|-|--|
| memcached |
[View](https://codechecker-demo.eastus.cloudapp.azure.com/Default/reports?run
NagyDonat wrote:
I found _yet another_ situation where unsigned numbers cause stupid errors in
the analyzer. This patch is a conservative, minimal solution to "plug the
hole", but perhaps it would be better to eliminate unsigned numbers from the
out-of-bound calculations and ensure that all co
llvmbot wrote:
@llvm/pr-subscribers-clang
@llvm/pr-subscribers-clang-static-analyzer-1
Author: None (NagyDonat)
Changes
A memory access is an out of bounds error if the offset is < the extent of
the memory region. Notice that here "<" is a _mathematical_ comparison
between two numbers an
https://github.com/NagyDonat created
https://github.com/llvm/llvm-project/pull/81034
A memory access is an out of bounds error if the offset is < the extent of the
memory region. Notice that here "<" is a _mathematical_ comparison between two
numbers and NOT a C/C++ operator that compares two
11 matches
Mail list logo
