haoNoQ wrote: Yes, right, this is more of a side effect of how we do things, not quite the intended behavior. In particular, if you write something out of bounds first, we will no longer report it as an uninitialized read, even though it's still an out-of-bounds read: https://godbolt.org/z/PYaYa1Yos
So either way we've obtained a proof that it wasn't "initialized" through any legal means, and we've even considered some illegal means! (Initializations through formally-unrelated objects don't work this way. For example, if you have stack variables `int x[5]` and `int y`, and `y` happens to share the same address as `x[9]` in the final binary, then the code `y = 7; x[9]++;` would still produce an uninitialized read warning in the static analyzer. But if `x` and `y` are fields in the same struct, we'll be able to see whether the offset is shared between them and we'll throw away the warning.) So I'm still mildly in favor of simply saying "uninitialized". It may or may not be someone else's actively used memory but that's beyond the programmer's control and they know it (hopefully). It would be somewhat dishonest to give the user an impression that this checker has considered the object's bounds before emitting a warning. Both the checker and the engine itself effectively ignore allocation bounds for all intents and purposes. https://github.com/llvm/llvm-project/pull/126596 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
