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

RFC : turn the interpreter into the reference semantics for GOTO programs #8277

Open
martin-cs opened this issue May 8, 2024 · 2 comments
Open
Assignees
Labels
RFC Request for comment

Comments

@martin-cs
Copy link
Collaborator

Originally a valid GOTO program was one generated by goto_convert from the C front-end. This is not an ideal definition but it did the job for a while. As other language front-ends rise in importance it becomes a less useful definition. As a result there have been a number of questions about what constitute valid GOTO programs ( #7471 #6495 ) and their semantics ( #8258 #8223 #8196 #7072 #4323 #2031 ).

Having a declarative semantics would be mathematically and conceptually appealing but many of the practical benefits would be achieved by having an executable semantics. So, I propose turning the interpreter https://github.com/diffblue/cbmc/blob/develop/src/goto-programs/interpreter_class.h into the "formal semantics" of GOTO programs. This is mostly just documentation, adding checks, invariants and assumptions and possibly some testing.

@martin-cs martin-cs added the RFC Request for comment label May 8, 2024
@martin-cs
Copy link
Collaborator Author

CC @tautschnig w.r.t. our earlier discussion

@peterschrammel
Copy link
Member

It might be worth using our test suites to automatically sanity cross-check the various implementations we have (interpretation, BMC, goto-analyzer). It's likely that they disagree in a few cases and we need to make a call which of them is actually right/intended/desired.

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

No branches or pull requests

3 participants