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

AutoCorres abstraction allows me to prove an invalid Hoare triple #18

Closed
sdconsta opened this issue Mar 21, 2017 · 4 comments
Closed

AutoCorres abstraction allows me to prove an invalid Hoare triple #18

sdconsta opened this issue Mar 21, 2017 · 4 comments
Labels

Comments

@sdconsta
Copy link

sdconsta commented Mar 21, 2017

Using AutoCorres 1.2 to abstract some C code, I discovered that I was able to prove some invalid Hoare triples. But I was not able to prove those same Hoare triples on the C-SIMPL output, which leads me to believe that this is specifically an AutoCorres issue. In brief, it seems that reading/writing from/to heap memory using a pointer, automatically asserts that the pointer is properly aligned and non-null.

I have provided code which demonstrates the issue. The function bar() increments a static pointer, which should not preserve the invariant c_guard on the pointer. Indeed, the invariant is unprovable. The function foo() also increments the pointer, but additionally writes to the pointed-to memory. This somehow makes the c_guard invariant provable.

Any assistance would be much appreciated. If this isn't the right place to post an AutoCorres issue, please let me know.

Scott Constable

Test.zip

@lsf37
Copy link
Member

lsf37 commented Mar 21, 2017

Hi Scott,

in the test file you're using the partial correctness Hoare triples that assume guards and asserts (which pointer validity is translated to).

To get the ones you want, you'd either prove "no_fail P f" independently, or you'd use the total correctness triples (validNF, i.e. the "<lbrace> .. <rbrace> f <lambda> .. <rbrace>!" syntax -- note the "!" at the end).

Cheers,
Gerwin

@lsf37
Copy link
Member

lsf37 commented Mar 21, 2017

Just to explain why this strange division (we recently had a discussion about this internally as well): in our refinement proofs, no_fail is implied by the refinement we're proving, so it'd be wasted effort to prove it twice -- that's why there is a version of Hoare triples that assume them instead of asserting them, and it's also the reason that version is the default syntax.

@lsf37 lsf37 added the question label Mar 21, 2017
@talsewell
Copy link

talsewell commented Mar 21, 2017 via email

@sdconsta
Copy link
Author

Excellent explanations from both of you. This fully explains the behavior I was witnessing. Thanks!

Scott

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants