Conversation
|
The Windows 2025 release job failed in The two inputs contain only global declarations, so the changed function-call/member-address path is not exercised. Dump creation/removal and this test are unchanged by the PR. Five repetitions with the untouched baseline and five with the patch passed locally with Could a maintainer rerun this Windows job once? The rerun API requires repository administrator rights. I have left the cleanup assertion and source unchanged rather than masking this intermittent failure. |
| if (arg->isCpp()) { | ||
| // A class/enum address-of expression may call a member, inherited or | ||
| // free operator& that returns storage unrelated to this object. | ||
| const ValueType* vt = member ? member->valueType() : nullptr; | ||
| if (!vt || vt->typeScope || (!vt->pointer && !vt->isIntegral() && !vt->isFloat())) | ||
| return nullptr; | ||
| } |
There was a problem hiding this comment.
This is an AI review. Take it with a grain of salt and feel free to reject it by resolving the comment.
I confirmed that the C false positive is fixed. However, this C++ restriction means the typical intrusive-list case is still reported when the same code is compiled as C++. The embedded node is a struct, so vt->typeScope is set:
#include <stdlib.h>
struct node { struct node *next; };
struct item { int x; struct node n; };
void list_add(struct node *n);
void f1(void) {
struct item *p = malloc(sizeof(*p));
if (!p) return;
list_add(&p->n);
p->x = 0;
}With this PR, a.c gives no warning but a.cpp still gives memleak at line 10.
Rejecting every class type to guard against an overloaded operator& seems very conservative. Maybe only reject when the type actually could overload it, for example when typeScope (or a base class) declares an operator&, or allow C-like structs whose functionList is empty? A free operator& is admittedly harder to rule out. If the restriction is kept on purpose, a TODO test for the C++ variant would document the limitation.
2 participants
Passing an embedded list node to a retaining function currently leaves its containing allocation classified as unused, producing the C memory-leak false positive in Trac #6259. A following unrelated statement exposes the issue; a final unknown call can already suppress it through a separate fallback.
Record possible usage of the allocation when a call receives the address of one of its embedded members. Walk member/type information to find the owning raw-pointer variable, stopping at a separately pointed-to object. Require the address to be the complete argument value, optionally through pointer casts. Keep allocation/deallocation history intact, and respect leak-ignore and pure-function configuration.
The C++ path accepts only known scalar/pointer member types and rejects static/reference storage and overloaded member access. Class, enum and unknown C++ terminal member types are conservatively excluded to avoid assuming built-in
operator&semantics. This extends possible-use handling; it does not prove that an unknown callee retains or frees the allocation. Existing--check-libraryconfiguration information remains appropriate for unmodeled calls.Validation on Windows with Clang 22.1.8 and CMake/Ninja (Debug, PCH disabled, serial build):
git diff --checkpasses. GUI and non-Windows CI have not been run locally.Please assign this work to KiritoYG if needed and consider it under the published $10 bounty schedule, subject to acceptance and the required ticket closure. Please confirm eligibility and the supported settlement route; GitHub Sponsors is available if accepted. No award or payment is being claimed.