[clang] [analyzer] Don't invalidate pointee of pointer-to-const on callback arguments (PR #225489)

DonĂ¡t Nagy via cfe-commits cfe-commits at lists.llvm.org
Wed Oct 21 06:54:11 PDT 2026


NagyDonat wrote:

While I was thinking about the issue noticed by claude, I also found **another thing to fix:**

Recall that earlier I wrote that there are
> _three_ kinds of calls that should be handled differently in `checkPointerEscapeAux`:
> 
> * (1) Calls that MallocChecker ignores when memory escapes to them (most system functions: the checker should see that `printf` calls won't release the memory)
> 
> * (2) Calls for which MallocChecker marks memory escaping to them as "Escaped" if it escaped through a pointer-to-non-const, but ignores memory escaping to them via pointer-to-const parameters (most user-defined functions, some system functions)
> 
> * (3) Calls for whichMallocChecker marks memory escaping to them as "Escaped" even if it escaped through a pointer-to const parameter (some exceptional functions listed by various heuristics).

Under the old system, these were implemented as:
- (3) = calls where `Call->argumentsMayEscape()` is true, so we have `IsConstPointerEscape == false` even for pointer-to-const parameters.
- (2) = calls where `mayFreeAnyEscapedMemoryOrIsModeledExplicitly` returns true but `Call->argumentsMayEscape()` was false.
- (1) = other calls.

Your PR moves many heuristics (namely the ones that were previously implemented directly in `mayFreeAnyEscapedMemoryOrIsModeledExplicitly`) from category (2) to category (3), and this is a problem.

You should revert and avoid this unwanted change in the behavior of these heuristics.

-------

_I'm also thinking about ways to split up this PR, because it is near the boundary where I can't understand it well enough to confidently say that it's correct. :thinking: Perhaps we should avoid touching `mayFreeAnyEscapedMemoryOrIsModeledExplicitly` in this functional change, and then refactor it in a non-functional follow-up?_



https://github.com/llvm/llvm-project/pull/225489


More information about the cfe-commits mailing list