-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unfolding with no permissions and predicate well-definedness #444
Comments
This seems to be able to lead to more general unsoundness as seen in the following example
This verifies with both backends |
I think I'm in favour of Malte's suggestion, although we generally allow for The alternative would be to have the backends explicitly case-split on none values and not use the body in this case. An advantage would be flexibility in the scenarios above (and a bit more consistency with how |
This also seems to affect unfolding for example
also verifies with both backends |
You raised an interesting point about "unfold as much predicate as I have", @alexanderjsummers. Conditionals could help here, e.g. I like the solution you proposed (case split), and regarding your final question: I'd be surprised if it caused problems in situations where code is parametrised with a symbolic permission amount On the other hand, I'm a bit worried about the effect (on the implementation and performance) that the additional branching will have in Silicon. Regarding performance, the effect would probably be analogous to that of additional user-provided conditionals (as mentioned above), but it will complicate the implementation (unlike user-provided conditionals). |
We discussed this in the Viper meeting on September 19th and decided to forbid unfolding with no permissions. |
Consider the following example:
Silicon reports insufficient permissions to
x.f
at theunfold
statement (because it can't find a heap chunk with non-zero permissions that would allow readingx.f
).Carbon happily verifies the program, although, I would argue,
y != null
should not be implied ifx.f
can't even be read.I would suggest to simply disallow unfolding with no permissions.
The text was updated successfully, but these errors were encountered: