Closed danieldietsch closed 7 years ago
Ok, here is a new proposal:
Hi All, Matthias Heizmann, Vincent Langenfeld and I would like to renew our proposal for an LTL property verification category. We would like to add this category as demo category to SV-COMP'17 and have a run before we meet in Uppsala at the end of April.
The following rules should apply for this category
Team Ultimate has already prepared an initial set of verification tasks (cf. pull request ...) and modified benchexec (cf. pull request #234) such that the category can take place.
Best, Daniel
Revised version. Changes: merged bullets, tried to use SV-COMP terminology, emphasize that we only extend existing formalisms.
Hi All, Matthias Heizmann, Vincent Langenfeld and I would like to renew our proposal for an LTL property verification category. We would like to add this category as demo category to SV-COMP'17 and have a run before we meet in Uppsala at the end of April.
The following rules should apply for this category
Additional comments
Team Ultimate has already prepared an initial set of verification tasks (cf. pull request ...) and modified benchexec (cf. pull request #234) such that the category can take place.
Best, Daniel
Looks good except two things:
The string init(main()) refers to the set of states in which the program can be directly after the main function was called without arguments.
The string init(
Verifiers have to check whether the LTL formula \phi holds in each init(main()) state.
Verifiers have to check whether the LTL formula \phi holds starting in each init(main()) state.
Regarding SPOT: Dirks quote was
- Is the reference to Spot required? It is bad to have the definition not self-contained. If it is only about omitting X, then the user does not need to read about Spot. Everything seems standard and not Spot-specific at all.
I propose the following change.
We use only the fragment of LTL properties that can be defined without the "next" operator. We use the following subset of the Spot [1] tool's syntax \phi := "P" | \phi || \phi | \phi && \phi | !\phi | G \phi | F \phi | \phi U \phi | \phi W \phi | \phi R \phi where \phi is a temporal formula and "P" is an atomic proposition.
We use only the fragment of LTL properties that can be defined without the "next" operator. We use the following syntax. \phi := "P" | \phi || \phi | \phi && \phi | !\phi | G \phi | F \phi | \phi U \phi | \phi W \phi | \phi R \phi where \phi is a temporal formula and "P" is an atomic proposition. Note that this is a subset of the Spot [1] tool's syntax.
Regarding main()
:
We already support arbitrary entry functions. I want to avoid confusion between "main function" and "main()".
Latest version for reference (cf. mail)
Hi All, Matthias Heizmann, Vincent Langenfeld and I would like to renew our proposal for an LTL property verification category. We would like to add this category as demo category to SV-COMP'17 and have a run before we meet in Uppsala at the end of April.
The following rules should apply for this category
CHECK( init(main()), LTL(\phi) )
, where \phi is an LTL formula. The string init()
refers to the set of states in which the program can be directly after the function was called. Usually, is main()
, i.e., a call without arguments to the entry function of the program. We note that e.g., global variables have been initialized at this point (see §5.1.2 of the C99 standard). Verifiers have to check whether the LTL formula \phi holds starting in each init(main())
state.Additional comments
x==0
is valid in a scope where x
does not occur.Team Ultimate has already prepared an initial set of verification tasks (cf. pull request ...) and modified benchexec (cf. pull request #234) such that the category can take place.
Best, Daniel
In the (Demo)Category, we check whether C programs satisfy LTL properties.
Each verification task consists of a C program and a .prp property file. Each .prp files corresponds to one program, the program filename is prefix of prp file. For each program there can be several .prp files. The verdict (_true-??? or _false-???) of each verification task is encoded in the filename of the .prp file.
The initial proposal for an LTL demo category was sent to the SVCOMP list as follows.
We should create an updated proposal here that contains all the issues that were raised in the past.