[clang] [analyzer] Update the undefined assignment checker diagnostics to not use the term 'garbage' (PR #126596)

Artem Dergachev via cfe-commits cfe-commits at lists.llvm.org
Thu Feb 13 22:00:43 PST 2025


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


More information about the cfe-commits mailing list