NagyDonat wrote:
> This is a sufficiently strong contract in the static analyzer; I'm not aware
> of any long-lived undefined values and I'd consider it a bug if I ever see a
> long-lived undefined value. I'm pretty sure there are a few assertions that
> would crash if this ever happened.
>
> So you can try to rely on this implicit contract to send a stronger message.
> For example:
>
> ```diff
> - ++x; // expected-warning{{The expression is an uninitialized value. The
> computed value will also be garbage}}
> + ++x; // expected-warning{{Uninitialized variable incremented}}
> ```
>
> ```diff
> - int y = x; // expected-warning@-1{{Assigned value is garbage or
> undefined}}
> + int y = x; // expected-warning@-1{{Value of uninitialized variable
> assigned}}
> ```
>
> ```diff
> - b.x |= 1; // expected-warning{{The left expression of the compound
> assignment is an uninitialized value. The computed value will also be
> garbage}}
> + b.x |= 1; // expected-warning{{Uninitialized variable used in compound
> assignment}}
> ```
On the other hand, directly saying "uninitialized" could be a good direction
because it's more concise and you're right that it's pretty much the only
source of `UndefinedVal`s in the analyzer.
> (You might want to make a distinction between variables and fields. But even
> if you don't, it's not unreasonable to simply say "variable" unconditionally,
> even without looking at the exact expression. You can use the word "location"
> if you're worried about locations of exotic nature. But you can be fairly
> certain that it's always going to be _a_ location, not any other source of
> values.)
I'd suggest writing "uninitialized memory" to (1) support the common case where
the memory comes from `malloc()` et al. and (2) dodge the distinction between
variable/field/etc.
https://github.com/llvm/llvm-project/pull/126596
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
