Lines Matching full:we
14 I've seen a few false positives that appear because we construct
34 Ideally, we should be able to model the initializer list's methods precisely.
41 which would be of type ``T*`` and represent ``begin()``, so we'd trivially model ``begin()``
53 Approach (1): If only we enabled ``ProgramState::bindLoc(..., notifyChanges=true)``
57 conservative as the current patch's solution. Ideally, we do not want escapes to
58 happen so early. Instead, we'd prefer them to be delayed until the list itself
62 would be the right thing to do. Currently we didn't think about that because we
65 Approach (2): We could teach the Store to scan itself for bindings to
70 Approach (3): We could let checkers maintain the set of active metadata symbols
76 Approach (4): We could allow checkers to trigger pointer escapes in arbitrary
77 moments. If we allow doing this within ``checkPointerEscape`` callback itself, we
80 with maximum stress on the checkers - still not too much stress when we have
91 Sometimes we model library aspects in the engine and model language constructs in checkers.
93 * What is the checker programming model that we are aiming for? Maximum freedom or more easy checke…
95 I think if we aim for maximum freedom, we do not need to worry about the
96 potential stress on checkers, and we can introduce abstractions to mitigate that
98 If we want to simplify the API, then maybe it makes more sense to move language
108 * I do care about performance in this case. The reason is that we have a
109 limited performance budget. And I think we should not expect most of the checker
111 have less nice/more verbose API for language modeling if we can have better
118 * To me it seems obvious that we need to aim for a checker API that is both
127 * Separation between core and checkers is usually quite strange. Once we have
139 > Approach (2): We could teach the Store to scan itself for bindings to
148 actual metadata value. So we'd be escaping more stuff than necessary.
150 If only we had "ghost fields"
154 belief that ghost fields are exactly what we need for most C++ checkers.
184 this to be in the store: we are modeling reachable storage as storage. But if
185 we're just modeling arbitrary analysis facts that need to be invalidated when a
186 pointer escapes then we shouldn't try to gin up storage for them just to get
198 Yeah, this is what we can easily implement now as a
199 symbolic-region-based-on-a-metadata-symbol (though we can make a new region
200 class for that if we eg. want it typed). The problem is that the relation
206 abstract storage is most of the time at best a "nice to know" thing - we cannot
207 rely on it to do any actual work. We'd anyway need to rely on the checker to do
218 I'd like to consider another funny example. Suppose we're trying to model
239 could of course break the uniqueness invariant (though we'd probably want it).
244 (which is in fact the problem we're dealing with in this patch - escaping the
247 So we're talking about one more operation over the program state (scanning
250 We can probably add a new callback "checkReachableSymbols" to solve this. This
251 is in fact also related to the dead symbols problem (we're scanning for live
252 symbols in the store and in the checkers separately, but we need to do so
254 idea; we can replace checkLiveSymbols with checkReachableSymbols.
256 Or we could just have ghost member variables, and no checker support required at
279 But, to summarize a bit, in our current case, however, the typestate we're
280 looking for is the contents of the heap. And when we try to model such
281 typestates (complex in this specific manner, i.e. heap-like) in any checker, we
289 > sense for this to be in the store: we are modeling reachable storage as
290 > storage. But if we're just modeling arbitrary analysis facts that need to be
291 > invalidated when a pointer escapes then we shouldn't try to gin up storage
302 Similarly, i think it's fine if we have a ``CXXRecordDecl`` with
304 abstraction (we don't even need to know its name or offset, only that it's there
309 We've discussed it in person with Devin, and he provided more points to think
322 * Because "ghost variables" are not material to the user, we need to somehow