You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am running into a rather interesting issue regarding the typestate analysis in combination with using pointer analysis. Assume the following simplified example:
Suppose I'd like to know the possible states of the objects c points to at the line c.p(). Also assume that my DFA has states, namely, "start" and "n." The "start" state is the initial state and calls to n() transitions us to state "n." The numbered comments are abstract objects created at the corresponding lines.
The points-to set of c at the call c.p() should be {1,2}. If we run the typestate analysis and use the resulting domain to give us the facts regarding these two objects at the basic block corresponding to call c.p(), we'd have that object 1 may either have the state "n" (in the case that the else branch is taken) or the state "start" (in the case that the if branch is taken). The former scenario is troubling because in the case that the if branch is taken, c would never point to object 1 because it is overwritten with object 2. As such, object 1 could only really be in the "n" state at this point.
My question is threefold:
Is this an inherent limitation of typestate analysis when combined with points-to analysis? Or, am I not using the points-to analysis correctly?
Is this some sort of sensitivity or precision problem that can be fixed?
Or, is this a limitation of SAFE, for which it can be improved upon?
The text was updated successfully, but these errors were encountered:
I am running into a rather interesting issue regarding the typestate analysis in combination with using pointer analysis. Assume the following simplified example:
Suppose I'd like to know the possible states of the objects
c
points to at the linec.p()
. Also assume that my DFA has states, namely, "start" and "n." The "start" state is the initial state and calls ton()
transitions us to state "n." The numbered comments are abstract objects created at the corresponding lines.The points-to set of
c
at the callc.p()
should be {1,2}. If we run the typestate analysis and use the resulting domain to give us the facts regarding these two objects at the basic block corresponding to callc.p()
, we'd have that object 1 may either have the state "n" (in the case that theelse
branch is taken) or the state "start" (in the case that the if branch is taken). The former scenario is troubling because in the case that theif
branch is taken,c
would never point to object 1 because it is overwritten with object 2. As such, object 1 could only really be in the "n" state at this point.My question is threefold:
The text was updated successfully, but these errors were encountered: