-
Notifications
You must be signed in to change notification settings - Fork 273
Discussion : structural invariants on goto-programs #1746
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
Comments
What is the performance optimisation enabled by this assumption? |
It's not performance, it is correctness : https://github.com/diffblue/cbmc/blob/develop/src/analyses/interval_domain.cpp#L84 |
Why wouldn't it take a join at the GOTO target location (next)? |
The current implementation is simply unsound. Assumptions on the absence of certain control flow patterns are not a good idea and should be fixed. |
OK, will fix all instances. |
At which points in the system, if any, is it acceptable to have a GOTO instruction whose target is the next instruction? For example:
if CONDITION goto next;
next : ...
I ask because remove_skip recognises (and removes) this case and many of the older abstract domains are written (implicitly) assuming it does not occur. So can/should we always assume that remove_skip has been run after any program transformations / input? Or should I update the domains so they are correct for this kind of program?
The text was updated successfully, but these errors were encountered: