On Aug 11, 2011, at 3:52 PM, Jordy Rose wrote: > On Aug 11, 2011, at 15:42, Ted Kremenek wrote: > >> ]As for not many symbols having multiple dependents, I don't think that's a >> valid assumption. The whole point of this addition was to give checkers the >> ability to tie two symbols together (e.g., parameter out value and a return >> value). There's no reason why there can't be multiple dependents. Even if >> it's just two checkers that need to track dependencies between a common >> symbol and another, two is still more than one. > > Sorry, I meant multiple dependenCIES. My bad. With the dependency > capabilities in this commit we have "this symbol survives if ANY of its base > symbols are alive", and no way to express "all of its base symbols".
Ah, I see what you mean. I think these are two separate concepts. This commit supports the "this symbol survives if ANY of its base symbols are alive", and I think that's a valid feature to support. The idea is that a checker indicates that it wants to extend the lifetime of one symbol to be at least as long as the lifetime of another. I think the confusion here is the terminology "base". This isn't an issue of one symbol being derived from another; it's about linking the lifetime of two existing symbols. > I think we might want to say that multiple dependencies = undefined behavior. I think for the intention of this feature, I don't think that's valid. I think we have two things: (1) Derived symbols. Derived symbols are mostly used to lazily symbolicate memory. They naturally have a notion of a *SINGLE* base. There is no real reason to support multiple bases. Lifetime of the derived symbol is dictated by the lifetime of the base symbol. (2) Linked symbols. Two symbols can be linked without having any other relationship to another. That's the intention of this commit.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
