RFC: Unreachable properties should be marked "UNREACHABLE" not "SUCCESS"

[danielsn]

It is confusing to users when an unreachable property succeeds

[SaswatPadhi]

Sounds somewhat related to #6057. A false assumption makes subsequent assertions essentially unreachable.

[jimgrundy]

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]

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).

[jimgrundy]

"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]

Just bringing this to the attention of @remi-delmas-3000