andyames-a11y wrote: One more data point that might be useful context. I traced the actual `SVal` shape reaching `bindArray` in our real production crash test case (not just the reduced repro) by instrumenting the relevant header with `clang_analyzer_dump` calls. There's no explicit pointer-to-integer cast anywhere in the source — instead, the value the analyzer builds is a "derived" symbol combining an opaquely-conjured int with an Element region whose base is itself a conjured `void *` symbol, most likely the analyzer's fallback representation of an un-inlined allocator call inside one of our custom container types.
That makes me wonder (genuinely unsure, would appreciate a sanity check) whether this bug class disproportionately affects codebases using custom/non-std containers, smart pointers, and allocators specifically because they don't benefit from the analyzer's existing special-casing for standard library facilities — things like BodyFarm's synthesized bodies, SmartPtrModeling for `std::unique_ptr`, and the StdLibraryFunctionsChecker API summaries. Those all exist to keep the analyzer from ever needing to fully symbolically execute the real (often deep, allocator-templated) internals of standard containers. If a codebase has its own container/smart-pointer/allocator types instead, none of that shortcut modeling applies, and the analyzer is forced down the same "conjure a symbol and derive a value from it" path we're seeing here — which is what seems to be tripping the missing type guard. I want to flag that as a hypothesis rather than something I've verified against the analyzer's internals — I don't know this codebase's checker architecture nearly as well as you do, so if there's reason to think that's off-base (or if there's already tooling/telemetry that would confirm or refute it), I'd genuinely like to know. But if it holds up, it might mean this bug's practical reach is bigger than the minimal repro suggests — worth keeping in mind for anyone maintaining a non-STL-heavy C++ codebase. https://github.com/llvm/llvm-project/pull/210200 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
