2014
DOI: 10.1007/978-3-642-54108-7_8
|View full text |Cite
|
Sign up to set email alerts
|

Abstract: Abstract. The simple and often imprecise specifications that programmers may write are a significant limit to a wider application of rigorous program verification techniques. Part of the reason why non-specialists find writing good specification hard is that, when verification fails, they receive little guidance as to what the causes might be, such as implementation errors or inaccurate specifications. To address these limitations, this paper presents two-step verification, a technique that combines implicit s… Show more

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1
1
1

Citation Types

0
17
0

Year Published

2015
2015
2023
2023

Publication Types

Select...
4
2

Relationship

4
2

Authors

Journals

citations
Cited by 11 publications
(17 citation statements)
references
References 40 publications
(43 reference statements)
0
17
0
Order By: Relevance
“…RELATED WORK Understanding proof failures. A two-step verification in [15] compares the proof failures of an Eiffel program with those of its variant where called functions are inlined and loops are unrolled. It reports code and contract revision suggestions from this comparison.…”
Section: Threats To Validitymentioning
confidence: 99%
“…RELATED WORK Understanding proof failures. A two-step verification in [15] compares the proof failures of an Eiffel program with those of its variant where called functions are inlined and loops are unrolled. It reports code and contract revision suggestions from this comparison.…”
Section: Threats To Validitymentioning
confidence: 99%
“…Dealing with inconclusive error reports in incomplete tools is a practical hurdle to usability that can spoil user experience-especially for novices. To improve user feedback in case of failed verification attempts, AutoProof implements a collection of heuristics known as "two-step verification" [35]. When they are enabled, each failed verification attempt is transparently followed by a second step that is in general unsound (as it uses under-approximations such as loop unrolling) but helps discern whether failed verification is due to real errors or just to insufficiently detailed annotations.…”
Section: Using Autoproofmentioning
confidence: 99%
“…2 already mentioned the Boogie Verification Debugger (BVD, [14]); the Spec# debugger [21] implements similar functionalities which construct concrete counterexamples from failed Boogie runs. Two-step verification [27] compares verification with different semantics (based on unrolling and inlining) to attribute verification failures to either inconsistent or incomplete specifications.…”
Section: Related Workmentioning
confidence: 99%