[clang] [analyzer] Check the correct first and last elements in cstring.UninitializedRead (PR #95408)
Kristóf Umann via cfe-commits
cfe-commits at lists.llvm.org
Thu Jun 20 01:26:05 PDT 2024
Szelethus wrote:
> The intention of the patch makes sense to me. However, I believe that the bug is inside the Store. It should not say it's `Undefined` if actually an existing binding overlaps (actually completely covers) the requested region. So, that said, the checker does the right thing, but the Store lies to it.
I disagree. Whether a value is _initialized_ or is _well defined_ are two different concepts (but happen to overlap in most cases). Reading the last byte of an integer as a character *should* yield an `Undefined` in my view. The Store doesn't lie here, we are asking the wrong question (what is the value of this byte?), and we don't have an interface for asking the right one (is this byte initialized). In this sense, the checker is doing the wrong thing :)
> And especially for memcpy-like raw memory manipulating APIs, implementing this element-type-wise check is really difficult. Partially because in CSA we have only limited trustworthy type information for such buffers.
>
> I'm also pragmatic with the subject, and believe in solutions today, than waiting for one years to come. But I still want to ask if we could join forces and implement the proposed Store model discussed here, as a counter proposal for the original RFC? For instance, that would make such loads not result in an Undefined value - unless it's actually uninitialized.
>
> (Once we had that Store model, we would probably want to revert this element-type-based solution outlined here.)
I think adding an "isUnitialized" interface would be better.
https://github.com/llvm/llvm-project/pull/95408
More information about the cfe-commits
mailing list