You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm used to a model checker that offers the following primitive concepts:
assume(p) : add p to the path condition
assert(p) : attempt to satisfy (path & ~p). If satisfied report error. If unsat, report success. (checks a universal property)
cover(p) : attempt to satisfy (path & p). If unsatisfiable report error. If sat, report success. (checks an existential property)
@kroening mentioned the other day that CBMC (used to) support a cover primitive like this, but it didn't seem to get used much, or maybe people didn't find it intuitive. My experience was that this construct was extremely valuable for debugging.
Imagine a world in which you have this construct. Then you can achieve the goal we are shooting for here by transforming:
assume(p);
into
cover(p); assume(p);
My former tool (Jasper) would also perform the following transformation automatically (controllable with a switch):
assert(p -> q);
into
cover(p);
assert(p -> q);
For the situation @danielsn describes one would transform an assert as follows:
assert(p);
into
cover(true);
assert(p);
One of our team just spend I think a full day debugging a vacuous assumption.
If you are happy to run a separate command then you can achieve that by running CBMC with the --cover assertion option, which checks __CPROVER_assert(false) (non-aborting) instead of assert(p).
"If you are happy to run a separate command then you can achieve that by running CBMC with the --cover assertion option, which checks __CPROVER_assert(false) (non-aborting) instead of assert(p)."
A separate command could be fine. It doesn't do all I might want (wouldn't have helped our team mate notice which assumption caused the contradiction), but it might do all that this issue is asking for. What do you think @SaswatPadhi and @danielsn, does that address this issue? Can we close this?
Activity
SaswatPadhi commentedon Aug 6, 2021
Sounds somewhat related to #6057. A
false
assumption makes subsequent assertions essentially unreachable.jimgrundy commentedon Aug 18, 2021
Agree that this is related to #6057.
Re-phrasing my comments from that issue:
I'm used to a model checker that offers the following primitive concepts:
assume(p) : add p to the path condition
assert(p) : attempt to satisfy (path & ~p). If satisfied report error. If unsat, report success. (checks a universal property)
cover(p) : attempt to satisfy (path & p). If unsatisfiable report error. If sat, report success. (checks an existential property)
@kroening mentioned the other day that CBMC (used to) support a cover primitive like this, but it didn't seem to get used much, or maybe people didn't find it intuitive. My experience was that this construct was extremely valuable for debugging.
Imagine a world in which you have this construct. Then you can achieve the goal we are shooting for here by transforming:
assume(p);
into
cover(p); assume(p);
My former tool (Jasper) would also perform the following transformation automatically (controllable with a switch):
assert(p -> q);
into
cover(p);
assert(p -> q);
For the situation @danielsn describes one would transform an assert as follows:
assert(p);
into
cover(true);
assert(p);
One of our team just spend I think a full day debugging a vacuous assumption.
peterschrammel commentedon Aug 18, 2021
If you are happy to run a separate command then you can achieve that by running CBMC with the
--cover assertion
option, which checks__CPROVER_assert(false)
(non-aborting) instead ofassert(p)
.jimgrundy commentedon Aug 19, 2021
"If you are happy to run a separate command then you can achieve that by running CBMC with the --cover assertion option, which checks __CPROVER_assert(false) (non-aborting) instead of assert(p)."
A separate command could be fine. It doesn't do all I might want (wouldn't have helped our team mate notice which assumption caused the contradiction), but it might do all that this issue is asking for. What do you think @SaswatPadhi and @danielsn, does that address this issue? Can we close this?
jimgrundy commentedon Aug 30, 2021
Just bringing this to the attention of @remi-delmas-3000