Skip to content

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

Open
@danielsn

Description

@danielsn

It is confusing to users when an unreachable property succeeds

Activity

added
awsBugs or features of importance to AWS CBMC users
on Aug 5, 2021
SaswatPadhi

SaswatPadhi commented on Aug 6, 2021

@SaswatPadhi
Contributor

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

jimgrundy

jimgrundy commented on Aug 18, 2021

@jimgrundy
Collaborator

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

peterschrammel commented on Aug 18, 2021

@peterschrammel
Member

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

jimgrundy commented on Aug 19, 2021

@jimgrundy
Collaborator

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

added
awsBugs or features of importance to AWS CBMC users
and removed
awsBugs or features of importance to AWS CBMC users
on Aug 24, 2021
jimgrundy

jimgrundy commented on Aug 30, 2021

@jimgrundy
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    RFCRequest for commentawsBugs or features of importance to AWS CBMC users

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @SaswatPadhi@peterschrammel@danielsn@jimgrundy

        Issue actions

          RFC: Unreachable properties should be marked "UNREACHABLE" not "SUCCESS" · Issue #6276 · diffblue/cbmc