Skip to content
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

java_verify happily uses method overrides with the wrong types #81

Closed
brianhuffman opened this issue Dec 23, 2015 · 0 comments
Closed
Assignees
Labels
obsolete Issues that involve/depend on deprecated code, such that they are not worth pursuing wontfix Closed issues that we decided not to fix, but are still potentially relevant

Comments

@brianhuffman
Copy link
Contributor

For example: Suppose Java method foo operates on arrays of arbitrary size. We can use java_verify to prove a method override foo_thm for foo with the array size fixed at, say, 10. Then suppose that method bar calls foo with an array argument of size 5. If we run java_verify on bar, passing in foo_thm as an override, then the generated proof obligations will be ill-typed.

In the LWE proofs (e.g. revision 96bc7d74 of saw-examples) this eventually produces errors like the following when we try to run z3 via the SBV backend:

Checking final assertions
./Data/Vector/Generic.hs:400 (slice): invalid slice (90,10,10)

To fix this, java_verify should compare the types of method overrides with the array sizes in the calling context, and refuse to apply the override if the types don't match.

@atomb atomb self-assigned this Mar 16, 2016
@atomb atomb added next priority High-priority issues labels Mar 16, 2016
@atomb atomb modified the milestone: 0.2-alpha Mar 30, 2016
@atomb atomb removed this from the 0.2-alpha milestone Apr 7, 2016
@atomb atomb added obsolete Issues that involve/depend on deprecated code, such that they are not worth pursuing and removed next priority High-priority issues labels Apr 2, 2019
@atomb atomb added the wontfix Closed issues that we decided not to fix, but are still potentially relevant label Jan 29, 2021
@atomb atomb closed this as completed Jan 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
obsolete Issues that involve/depend on deprecated code, such that they are not worth pursuing wontfix Closed issues that we decided not to fix, but are still potentially relevant
Projects
None yet
Development

No branches or pull requests

2 participants