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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
