andyames-a11y wrote: That was quick. I only needed to trace back one layer, into our custom string class that uses a custom allocator. Our custom span implementation is interacting with a subrange of our string.
There is a `void *`-based region in the string implementation. The string container's buffer pointer is established via: ``` // allocate(): return type is an allocator-defined "void pointer or error" type return GetAllocator().Allocate(Size + 1); // initialize(): the allocator's void*-flavored result gets cast to the real element pointer type Pointer_t tAllocation = static_cast<Pointer_t>(allocate(koLength).Value()); ``` The allocator's `Allocate()` is a template parameter, so its real implementation isn't inlined by the analyzer, which conjures an opaque `void *` symbol to stand in for its return value. That `static_cast<Pointer_t>(void*)` is exactly the seam where the region backing the container's buffer ends up rooted in a `void *`-typed symbol in the dump posted earlier. I'll caveat that this only confirms the `void *` half of the derived symbol — I haven't isolated where the other half (the opaquely-conjured int) comes from with the same confidence; my best guess is it's just the analyzer's generic placeholder for "unconstrained byte read from untracked heap memory" rather than a second distinct problem call site, but I haven't verified that as rigorously. Wanted to share what's actually nailed down rather than wait until everything is. https://github.com/llvm/llvm-project/pull/210200 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
