melver wrote: > Your reasoning is interesting, but we don't really know that the reason for a > cast is some kind of reallocation. It could be anything. Another problem is > that this makes the analysis less predictable. If we invalidate on the basis > of casts, users will have no idea what's going on when they change the code > and the warning pops up (or disappears). > > Not saying no, but I'm not quite convinced that this is the best way.
Replied here: https://github.com/llvm/llvm-project/pull/187691#issuecomment-4235756125 TLDR; because passing `Foo**` to another incompatible type (e.g. `void**`) requires an explicit cast, this rule is self-documenting. We aren't guessing at the callee's behavior; we are respecting the developer's explicit signal that the pointer's type safety - and thus its tracked identity - is being suspended at that boundary. IMHO, it's a clean, predictable rule for the analysis. If you're still not convinced, we can narrow it to the concrete examples I was using: at the very least I'd invalidate aliases after passing a pointer-to-alias with`void` casts. https://github.com/llvm/llvm-project/pull/190154 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
