=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/DonatNagyE closed
https://github.com/llvm/llvm-project/pull/72402
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
DonatNagyE wrote:
I'm merging this commit in its current shape because even if I'd reimplement a
warning for the "use of `alloc(0)`", I'd do it in a separate commit.
I thought about potential approaches to implement
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/steakhal approved this pull request.
Overall, I'm in favor of this change.
On the other hand, I'd urge for not to regress on the diagnostics.
To me, `alloca` is like a VLA; which is prone to misuses,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/DonatNagyE updated
https://github.com/llvm/llvm-project/pull/72402
>From 703c06e2d6781c45e55d7021929a06cdb0275a14 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Wed, 15 Nov 2023
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
DonatNagyE wrote:
> I think the original `alloca(0)` warning message might be clearer/easier to
> understand.
The difficulty is that we switch from the `SymbolicRegion` that represents the
heap allocation to an `AllocaRegion` that doesn't
Xazax-hun wrote:
I think the original `alloca(0)` warning message might be clearer/easier to
understand. While it might have platform or compiler dependent meaning, those
behaviors are non-portable, so I think it is undesirable in most cases and
people probably want to be notified about it.
=?utf-8?q?Don=C3=A1t?= Nagy
Message-ID:
In-Reply-To:
DonatNagyE wrote:
@haoNoQ What do you think about this commit? May I merge it?
https://github.com/llvm/llvm-project/pull/72402
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/DonatNagyE edited
https://github.com/llvm/llvm-project/pull/72402
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
@@ -81,22 +81,21 @@ bool BuiltinFunctionChecker::evalCall(const CallEvent ,
case Builtin::BI__builtin_alloca_with_align:
case Builtin::BI__builtin_alloca: {
-// FIXME: Refactor into StoreManager itself?
-
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/DonatNagyE updated
https://github.com/llvm/llvm-project/pull/72402
>From 703c06e2d6781c45e55d7021929a06cdb0275a14 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Wed, 15 Nov 2023 16:03:22 +0100
Subject:
@@ -266,13 +266,18 @@ void CheckUseZeroAllocated1(void) {
}
char CheckUseZeroAllocated2(void) {
+ // FIXME: The return value of `alloca()` is modeled with `AllocaRegion`
+ // instead of `SymbolicRegion`, so the current implementation of
+ //
https://github.com/gamesh411 edited
https://github.com/llvm/llvm-project/pull/72402
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -266,13 +266,18 @@ void CheckUseZeroAllocated1(void) {
}
char CheckUseZeroAllocated2(void) {
+ // FIXME: The return value of `alloca()` is modeled with `AllocaRegion`
+ // instead of `SymbolicRegion`, so the current implementation of
+ //
https://github.com/gamesh411 approved this pull request.
LGTM, added two remarks inline, but those can be separate patches as well.
https://github.com/llvm/llvm-project/pull/72402
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -81,22 +81,21 @@ bool BuiltinFunctionChecker::evalCall(const CallEvent ,
case Builtin::BI__builtin_alloca_with_align:
case Builtin::BI__builtin_alloca: {
-// FIXME: Refactor into StoreManager itself?
-MemRegionManager& RM =
https://github.com/DonatNagyE edited
https://github.com/llvm/llvm-project/pull/72402
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/DonatNagyE edited
https://github.com/llvm/llvm-project/pull/72402
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -266,13 +266,18 @@ void CheckUseZeroAllocated1(void) {
}
char CheckUseZeroAllocated2(void) {
+ // FIXME: The return value of `alloca()` is modeled with `AllocaRegion`
+ // instead of `SymbolicRegion`, so the current implementation of
+ //
DonatNagyE wrote:
> Hmm, it really worries me that `MallocChecker` is setting a return value
> outside of `evalCall()`. This can easily lead to conflicts if multiple
> checkers try to do this: `evalCall()` is protected from conflicts (the engine
> asserts that at most one checker evaluates
@@ -266,13 +266,18 @@ void CheckUseZeroAllocated1(void) {
}
char CheckUseZeroAllocated2(void) {
+ // FIXME: The return value of `alloca()` is modeled with `AllocaRegion`
+ // instead of `SymbolicRegion`, so the current implementation of
+ //
@@ -266,13 +266,18 @@ void CheckUseZeroAllocated1(void) {
}
char CheckUseZeroAllocated2(void) {
+ // FIXME: The return value of `alloca()` is modeled with `AllocaRegion`
+ // instead of `SymbolicRegion`, so the current implementation of
+ //
haoNoQ wrote:
Hmm, it really worries me that `MallocChecker` is setting a return value
outside of `evalCall()`. This can easily lead to conflicts if multiple checkers
try to do this: `evalCall()` is protected from conflicts (the engine asserts
that at most one checker evaluates each call) but
llvmbot wrote:
@llvm/pr-subscribers-clang-static-analyzer-1
@llvm/pr-subscribers-clang
Author: None (DonatNagyE)
Changes
...to model the results of alloca() and _alloca() calls. Previously it acted as
if these functions were returning memory from the heap, which led to
https://github.com/DonatNagyE created
https://github.com/llvm/llvm-project/pull/72402
...to model the results of alloca() and _alloca() calls. Previously it acted as
if these functions were returning memory from the heap, which led to
alpha.security.ArrayBoundV2 producing incorrect messages.
24 matches
Mail list logo
