DOCSLIB.ORG

Formal Verificat Formal Verification with Dafny

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

1 Formal Verification with Dafny Cedric Abano Gordon Chu Gabriel Eiseman Justin Fu Tiffany Yu [email protected] [email protected] [email protected] [email protected] [email protected] Abstract North American electric grid led to a blackout Computer programming and software that lasted 26 hours and affected 50 million engineering have found their way into many persons in Ohio, Michigan, Pennsylvania, New facets of the current world. In certain industries, York, Vermont, Massachusetts, Connecticut, correct computer programs are needed for basic New Jersey, and Ontario.1, 2 In 2007, Qantas operation. This absolute correctness could be flight 72 from Singapore to Perth unexpectedly proven by brute force, which involves passing in nose-dived twice due to a faulty stabilization all possible test cases through a program. This algorithm that failed to consider two consecutive technique is largely impractical, especially for sensor errors, injuring 119 passengers and crew complex programs that do not have a bounded members.3 These incidents are just a few input range. Alternatively, a more theoretical instances from a long list of occurrences where and feasible approach can be taken, using incorrect code crippled the integrity of a large mathematics and logical reasoning to prove the scale system, demonstrating the importance of correctness of a program. Formal verification is writing code that is correct in all cases at all a field of computer science dealing with the times. construction of mathematical proofs of programs’ correctness. This paper explores the 1.2 The Software Development Cycle current state of formal verification through While there are several different models Dafny, a static program verifier created by of the software development cycle, the steps in Microsoft Research. Dafny was used to each can be generalized to four main categories.4 implement five common algorithms and compared with lower-level methods of formal verification. Although there were qualities about Dafny that were difficult to work with, ultimately self-verification of programs has positive prospects for future developments. 1. Introduction Figure 1. The Software Development Cycle 1.1 Why is it important to write correct programs? During the specification phase of With the growing reliance on software software engineering, data is gathered about the for functionality in various industries, computer problem to be solved. Developers describe all programs have become increasingly involved in aspects of the issue formally and gain an operations that are responsible for the wellbeing understanding of the subtle intricacies of individuals. This enlarged scope of influence accompanying it. A written specification is often entails a moral obligation for programmers to created at this stage, describing how the write code that works correctly under all program is to behave under various conditions. conditions. Programs must be correct for all After the specification is completed, inputs, not just expected ones, as even the developers proceed to the design phase where smallest error can have disastrous they consider various algorithms to solve the consequences. In 2003, a flawed assumption in problem efficiently. This can involve using pre- FirstEnergy’s estimator program modeling the existing algorithms or creating entirely new algorithms to approach to the problem. The majority of coding is done during this stage. 2 Following the software design phase is 2. Background the validation phase. During validation, Up to this point, the word “correct” has developers write test code to ensure their been used informally to describe programs. The program works. Such code usually consists of following sections will develop a precise testing standard input and edge cases. definition of correctness, building up the Once a program passes its validation definition through the mathematical notation of tests, the development cycle is repeated in order propositional logic and employing it in Dafny. to refine the program. The code is improved by repeatedly reevaluating its specification, design, 2.1 A Brief Introduction to Propositional and validation. Logic A final note on the software It is often difficult to know for certain, development cycle is that the model shown that a given algorithm is correct, especially if above is not discreet. These phases are loosely that algorithm is particularly lengthy. In this defined and occur on a continuum, commonly situation, mathematics provides some certainty overlapping in the real world. in determining an algorithm’s correctness, specifically with a branch of mathematics known 1.3 Limitations of Validation as propositional logic. The primary component of the software Like all forms of logic, propositional development cycle this paper will scrutinize is logic concerns mathematical proofs. validation. When writing tests, programmers Propositional variables, or atoms, denoted by often use ad hoc logic to convince themselves capital letters (A, B, X) represent true or false that their code is correct. It is not feasible to test conditions and make up statements, or all inputs for nontrivial programs, and thus formulae, in propositional logic. More complex validation tests usually check a limited number conditions are derived from these simple of cases meant to represent a sample of probable statements using relationships, or connectors, inputs. If a programmer’s code passes these such as a disjunction, conjunction, negation, etc. tests, they believe that their implementation is (Figure 2). correct, even though there is insufficient evidence to make such a claim. Conjunction: A B denotes A AND B Furthermore, debugging, which is the Disjunction: A B denotes A OR B process of fixing erroneous programs in order to Negation: ¬A denotes∧ NOT A satisfy its tests, is a time-consuming and costly Implication: A∨ B denotes A IMPLIES B, equivalent process. Programmers spend as much as 49.9% to ¬A B ⇒ of their time debugging their code, accounting x denotes FOR ALL “X” ∨ for a total of $156 billion worldwide.5 x denotes There EXISTS a variable X ∀ Figure 2. Notation of Propositional Logic ∃ 1.4 Formal Verification The formulae created by these atoms Various resources are funneled into and connectives can be evaluated, and the truth writing correct programs, yet the standard values of these formulae, can be found by method used in software development lacks trivially following the relationships that the mathematical rigor. An effort introduced to connectives state. In some cases, a truth table remedy this discrepancy is formal verification. may be used to determine all possible truth Formal verification is a systematic approach to values of a formula, given different proving that a program is correct with regards to combinations of truth states of each atom (Table its specification.6 This paper will explore the 2). methodology of formal verification and demonstrate its current capabilities in determining a program’s correctness through a cutting-edge verification tool called Dafny. 3 2.3 Hoare Logic and Defining Correctness True is denoted with a 1 False is denoted with a 0 In the late 1960s, Sir Charles Antony Richard Hoare formalized a model for reasoning about the correctness of programs. The model, A B ¬A A ∧ B A B ⇒ which came to be known as Hoare logic, outlined 0 0 1 0 1 a schema for proving that a program implementation adheres to its specifications. 0 1 1 0 1 The general methodology behind a Hoare logic 1 0 0 0 0 proof of a program is to: 1. Start with a set of axioms that are assumed 1 1 0 1 1 to be true 2. Using propositional logic, develop a series of Figure 3. A truth table a few formula claims from these axioms and the computer code of the program Mathematical principles of substitution, 3. Demonstrate that the program’s double-negation, commutativity, associativity, postconditions are true at the end of the and distributivity can aid in the construction or program deconstruction of propositional formulae. Through this application of propositional logic Moreover, with the use of these principles, to computer programs, Hoare helped to define complex formulae, such as ¬(A ∧ B) ∨ C ⇒D, correctness by connecting a program’s can be broken down into more fundamental preconditions (P), code (Q), and postconditions formulae, A ∨ B ∨ ¬C ∨ D, and vice versa.7 (R). The principles of propositional logic, while having applications in mathematics, also “If the assertion P is true before the initiation of a have a relevant application in computer science. program Q, then the assertion R will be true on its Propositional logic forms the basis of automatic completion.”8 This relationship is called a Hoare theorem provers and other code verification Triple, and is denoted as: P {Q} R tools. Figure 4. Hoare Triples 2.2 Specifications, Preconditions and A rigorous definition of correctness can be Postconditions obtained from the definition of a Hoare triplet. Concerning correctness from a programmer’s perspective, specifications are used to define a program’s behavior with A program that executes code Q, with a specification particular sets of preconditions and consisting of a set of preconditions P and set of * postconditions. Preconditions are assumptions postconditions R, and terminates is correct with respect to its specification {P, R} if: that must be true when a program is invoked and postconditions are claims that must hold P ∧ Q ⇒ R true after a program terminates. For the Figure 5. Defining Correctness purposes of verification, it is important to write meaningful specifications that characterize the behavior of a program. Postconditions should reflect a defining property or relationship of a * Hoare logic can only prove the partial correctness of a program’s manipulated data after it is executed program, as opposed to the total correctness of a program. A and preconditions should ensure that these Hoare triplet makes no claim that the code Q terminates. If postconditions could be reached. Specifications the program never terminates, then it is impossible to assert the postconditions R.
Recommended publications
  • Ironpython in Action

    Ironpython in Action

    IronPytho IN ACTION Michael J. Foord Christian Muirhead FOREWORD BY JIM HUGUNIN MANNING IronPython in Action Download at Boykma.Com Licensed to Deborah Christiansen <[email protected]> Download at Boykma.Com Licensed to Deborah Christiansen <[email protected]> IronPython in Action MICHAEL J. FOORD CHRISTIAN MUIRHEAD MANNING Greenwich (74° w. long.) Download at Boykma.Com Licensed to Deborah Christiansen <[email protected]> For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact Special Sales Department Manning Publications Co. Sound View Court 3B fax: (609) 877-8256 Greenwich, CT 06830 email: [email protected] ©2009 by Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15% recycled and processed without the use of elemental chlorine.
  • Thriving in a Crowded and Changing World: C++ 2006–2020

    Thriving in a Crowded and Changing World: C++ 2006–2020

    Thriving in a Crowded and Changing World: C++ 2006–2020 BJARNE STROUSTRUP, Morgan Stanley and Columbia University, USA Shepherd: Yannis Smaragdakis, University of Athens, Greece By 2006, C++ had been in widespread industrial use for 20 years. It contained parts that had survived unchanged since introduced into C in the early 1970s as well as features that were novel in the early 2000s. From 2006 to 2020, the C++ developer community grew from about 3 million to about 4.5 million. It was a period where new programming models emerged, hardware architectures evolved, new application domains gained massive importance, and quite a few well-financed and professionally marketed languages fought for dominance. How did C++ ś an older language without serious commercial backing ś manage to thrive in the face of all that? This paper focuses on the major changes to the ISO C++ standard for the 2011, 2014, 2017, and 2020 revisions. The standard library is about 3/4 of the C++20 standard, but this paper’s primary focus is on language features and the programming techniques they support. The paper contains long lists of features documenting the growth of C++. Significant technical points are discussed and illustrated with short code fragments. In addition, it presents some failed proposals and the discussions that led to their failure. It offers a perspective on the bewildering flow of facts and features across the years. The emphasis is on the ideas, people, and processes that shaped the language. Themes include efforts to preserve the essence of C++ through evolutionary changes, to simplify itsuse,to improve support for generic programming, to better support compile-time programming, to extend support for concurrency and parallel programming, and to maintain stable support for decades’ old code.
  • Cornell CS6480 Lecture 3 Dafny Robbert Van Renesse Review All States

    Cornell CS6480 Lecture 3 Dafny Robbert Van Renesse Review All States

    Cornell CS6480 Lecture 3 Dafny Robbert van Renesse Review All states Reachable Ini2al states states Target states Review • Behavior: infinite sequence of states • Specificaon: characterizes all possible/desired behaviors • Consists of conjunc2on of • State predicate for the inial states • Acon predicate characterizing steps • Fairness formula for liveness • TLA+ formulas are temporal formulas invariant to stuering • Allows TLA+ specs to be part of an overall system Introduction to Dafny What’s Dafny? • An imperave programming language • A (mostly funconal) specificaon language • A compiler • A verifier Dafny programs rule out • Run2me errors: • Divide by zero • Array index out of bounds • Null reference • Infinite loops or recursion • Implementa2ons that do not sa2sfy the specifica2ons • But it’s up to you to get the laFer correct Example 1a: Abs() method Abs(x: int) returns (x': int) ensures x' >= 0 { x' := if x < 0 then -x else x; } method Main() { var x := Abs(-3); assert x >= 0; print x, "\n"; } Example 1b: Abs() method Abs(x: int) returns (x': int) ensures x' >= 0 { x' := 10; } method Main() { var x := Abs(-3); assert x >= 0; print x, "\n"; } Example 1c: Abs() method Abs(x: int) returns (x': int) ensures x' >= 0 ensures if x < 0 then x' == -x else x' == x { x' := 10; } method Main() { var x := Abs(-3); print x, "\n"; } Example 1d: Abs() method Abs(x: int) returns (x': int) ensures x' >= 0 ensures if x < 0 then x' == -x else x' == x { if x < 0 { x' := -x; } else { x' := x; } } Example 1e: Abs() method Abs(x: int) returns (x': int) ensures
  • Verification of Concurrent Programs in Dafny

    Verification of Concurrent Programs in Dafny

    Bachelor’s Degree in Informatics Engineering Computation Bachelor’s End Project Verification of Concurrent Programs in Dafny Author Jon Mediero Iturrioz 2017 Abstract This report documents the Bachelor’s End Project of Jon Mediero Iturrioz for the Bachelor in Informatics Engineering of the UPV/EHU. The project was made under the supervision of Francisca Lucio Carrasco. The project belongs to the domain of formal methods. In the project a methodology to prove the correctness of concurrent programs called Local Rely-Guarantee reasoning is analyzed. Afterwards, the methodology is implemented over Dagny automatic program verification tool, which was introduced to me in the Formal Methods for Software Devel- opments optional course of the fourth year of the bachelor. In addition to Local Rely-Guarantee reasoning, in the report Hoare logic, Separation logic and Variables as Resource logic are explained, in order to have a good foundation to understand the new methodology. Finally, the Dafny implementation is explained, and some examples are presented. i Acknowledgments First of all, I would like to thank to my supervisor, Paqui Lucio Carrasco, for all the help and orientation she has offered me during the project. Lastly, but not least, I would also like to thank my parents, who had supported me through all the stressful months while I was working in the project. iii Contents Abstracti Contentsv 1 Introduction1 1.1 Objectives..................................3 1.2 Work plan..................................3 1.3 Content...................................4 2 Foundations5 2.1 Hoare Logic.................................5 2.1.1 Assertions..............................5 2.1.2 Programming language.......................7 2.1.3 Inference rules...........................9 2.1.4 Recursion.............................
  • Neufuzz: Efficient Fuzzing with Deep Neural Network

    Neufuzz: Efficient Fuzzing with Deep Neural Network

    Received January 15, 2019, accepted February 6, 2019, date of current version April 2, 2019. Digital Object Identifier 10.1109/ACCESS.2019.2903291 NeuFuzz: Efficient Fuzzing With Deep Neural Network YUNCHAO WANG , ZEHUI WU, QIANG WEI, AND QINGXIAN WANG China National Digital Switching System Engineering and Technological Research Center, Zhengzhou 450000, China Corresponding author: Qiang Wei ([email protected]) This work was supported by National Key R&D Program of China under Grant 2017YFB0802901. ABSTRACT Coverage-guided graybox fuzzing is one of the most popular and effective techniques for discovering vulnerabilities due to its nature of high speed and scalability. However, the existing techniques generally focus on code coverage but not on vulnerable code. These techniques aim to cover as many paths as possible rather than to explore paths that are more likely to be vulnerable. When selecting the seeds to test, the existing fuzzers usually treat all seed inputs equally, ignoring the fact that paths exercised by different seed inputs are not equally vulnerable. This results in wasting time testing uninteresting paths rather than vulnerable paths, thus reducing the efficiency of vulnerability detection. In this paper, we present a solution, NeuFuzz, using the deep neural network to guide intelligent seed selection during graybox fuzzing to alleviate the aforementioned limitation. In particular, the deep neural network is used to learn the hidden vulnerability pattern from a large number of vulnerable and clean program paths to train a prediction model to classify whether paths are vulnerable. The fuzzer then prioritizes seed inputs that are capable of covering the likely to be vulnerable paths and assigns more mutation energy (i.e., the number of inputs to be generated) to these seeds.
  • Well-Founded Functions and Extreme Predicates in Dafny: a Tutorial

    Well-Founded Functions and Extreme Predicates in Dafny: a Tutorial

    EPiC Series in Computing Volume 40, 2016, Pages 52–66 IWIL-2015. 11th International Work- shop on the Implementation of Logics Well-founded Functions and Extreme Predicates in Dafny: A Tutorial K. Rustan M. Leino Microsoft Research [email protected] Abstract A recursive function is well defined if its every recursive call corresponds a decrease in some well-founded order. Such well-founded functions are useful for example in computer programs when computing a value from some input. A boolean function can also be defined as an extreme solution to a recurrence relation, that is, as a least or greatest fixpoint of some functor. Such extreme predicates are useful for example in logic when encoding a set of inductive or coinductive inference rules. The verification-aware programming language Dafny supports both well-founded functions and extreme predicates. This tutorial describes the difference in general terms, and then describes novel syntactic support in Dafny for defining and proving lemmas with extreme predicates. Various examples and considerations are given. Although Dafny’s verifier has at its core a first-order SMT solver, Dafny’s logical encoding makes it possible to reason about fixpoints in an automated way. 0. Introduction Recursive functions are a core part of computer science and mathematics. Roughly speaking, when the definition of such a function spells out a terminating computation from given arguments, we may refer to it as a well-founded function. For example, the common factorial and Fibonacci functions are well-founded functions. There are also other ways to define functions. An important case regards the definition of a boolean function as an extreme solution (that is, a least or greatest solution) to some equation.
  • Transforming Event-B Models to Dafny Contracts

    Transforming Event-B Models to Dafny Contracts

    Electronic Communications of the EASST Volume XXX (2015) Proceedings of the 15th International Workshop on Automated Verification of Critical Systems (AVoCS 2015) Transforming Event-B Models to Dafny Contracts Mohammadsadegh Dalvandi, Michael Butler, Abdolbaghi Rezazadeh 15 pages Guest Editors: Gudmund Grov, Andrew Ireland Managing Editors: Tiziana Margaria, Julia Padberg, Gabriele Taentzer ECEASST Home Page: http://www.easst.org/eceasst/ ISSN 1863-2122 ECEASST Transforming Event-B Models to Dafny Contracts Mohammadsadegh Dalvandi1, Michael Butler2, Abdolbaghi Rezazadeh3 School of Electronic & Computer Science, University of Southampton 1 2 3 md5g11,mjb,[email protected] Abstract: Our work aims to build a bridge between constructive (top-down) and analytical (bottom-up) approaches to software verification. This paper presents a tool-supported method for linking two existing verification methods: Event-B (con- structive) and Dafny (analytical). This method combines Event-B abstraction and refinement with the code-level verification features of Dafny. The link transforms Event-B models to Dafny contracts by providing a framework in which Event-B models can be implemented correctly. The paper presents a method for transforma- tion of Event-B models of abstract data types to Dafny contracts. Also a prototype tool implementing the transformation method is outlined. The paper also defines and proves a formal link between property verification in Event-B and Dafny. Our approach is illustrated with a small case study. Keywords: Formal Methods, Hoare Logic, Program Verification, Event-B, Dafny 1 Introduction Various formal methods communities [CW96, HMLS09, LAB+06] have suggested that no single formal method can cover all aspects of a verification problem therefore engineering bridges be- tween complementary verification tools to enable their effective interoperability may increase the verification capabilities of verification tools.
  • Programming Language Features for Refinement

    Programming Language Features for Refinement

    Programming Language Features for Refinement Jason Koenig K. Rustan M. Leino Stanford University Microsoft Research [email protected] [email protected] Algorithmic and data refinement are well studied topics that provide a mathematically rigorous ap- proach to gradually introducing details in the implementation of software. Program refinements are performed in the context of some programming language, but mainstream languages lack features for recording the sequence of refinement steps in the program text. To experiment with the combination of refinement, automated verification, and language design, refinement features have been added to the verification-aware programming language Dafny. This paper describes those features and reflects on some initial usage thereof. 0. Introduction Two major problems faced by software engineers are the development of software and the maintenance of software. In addition to fixing bugs, maintenance involves adapting the software to new or previously underappreciated scenarios, for example, using new APIs, supporting new hardware, or improving the performance. Software version control systems track the history of software changes, but older versions typically do not play any significant role in understanding or evolving the software further. For exam- ple, when a simple but inefficient data structure is replaced by a more efficient one, the program edits are destructive. Consequently, understanding the new code may be significantly more difficult than un- derstanding the initial version, because the source code will only show how the more complicated data structure is used. The initial development of the software may proceed in a similar way, whereby a software engi- neer first implements the basic functionality and then extends it with additional functionality or more advanced behaviors.
  • Developing Verified Sequential Programs with Event-B

    Developing Verified Sequential Programs with Event-B

    UNIVERSITY OF SOUTHAMPTON Developing Verified Sequential Programs with Event-B by Mohammadsadegh Dalvandi A thesis submitted in partial fulfillment for the degree of Doctor of Philosophy in the Faculty of Physical Sciences and Engineering Electronics and Computer Science April 2018 UNIVERSITY OF SOUTHAMPTON ABSTRACT FACULTY OF PHYSICAL SCIENCES AND ENGINEERING ELECTRONICS AND COMPUTER SCIENCE Doctor of Philosophy by Mohammadsadegh Dalvandi The constructive approach to software correctness aims at formal modelling of the in- tended behaviour and structure of a system in different levels of abstraction and verifying properties of models. The target of analytical approach is to verify properties of the final program code. A high level look at these two approaches suggests that the con- structive and analytical approaches should complement each other well. The aim of this thesis is to build a link between Event-B (constructive approach) and Dafny (analytical approach) for developing sequential verified programs. The first contribution of this the- sis is a tool supported method for transforming Event-B models to simple Dafny code contracts (in the form of method pre- and post-conditions). Transformation of Event-B formal models to Dafny method declarations and code contracts is enabled by a set of transformation rules. Using this set of transformation rules, one can generate code contracts from Event-B models but not implementations. The generated code contracts must be seen as an interface that can be implemented. If there is an implementation that satisfies the generated contracts then it is considered to be a correct implementation of the abstract Event-B model. A tool for automatic transformation of Event-B models to simple Dafny code contracts is presented.
  • Verification and Specification of Concurrent Programs

    Verification and Specification of Concurrent Programs

    Verification and Specification of Concurrent Programs Leslie Lamport 16 November 1993 To appear in the proceedings of a REX Workshop held in The Netherlands in June, 1993. Verification and Specification of Concurrent Programs Leslie Lamport Digital Equipment Corporation Systems Research Center Abstract. I explore the history of, and lessons learned from, eighteen years of assertional methods for specifying and verifying concurrent pro- grams. I then propose a Utopian future in which mathematics prevails. Keywords. Assertional methods, fairness, formal methods, mathemat- ics, Owicki-Gries method, temporal logic, TLA. Table of Contents 1 A Brief and Rather Biased History of State-Based Methods for Verifying Concurrent Systems .................. 2 1.1 From Floyd to Owicki and Gries, and Beyond ........... 2 1.2Temporal Logic ............................ 4 1.3 Unity ................................. 5 2 An Even Briefer and More Biased History of State-Based Specification Methods for Concurrent Systems ......... 6 2.1 Axiomatic Specifications ....................... 6 2.2 Operational Specifications ...................... 7 2.3 Finite-State Methods ........................ 8 3 What We Have Learned ........................ 8 3.1 Not Sequential vs. Concurrent, but Functional vs. Reactive ... 8 3.2Invariance Under Stuttering ..................... 8 3.3 The Definitions of Safety and Liveness ............... 9 3.4 Fairness is Machine Closure ..................... 10 3.5 Hiding is Existential Quantification ................ 10 3.6 Specification Methods that Don’t Work .............. 11 3.7 Specification Methods that Work for the Wrong Reason ..... 12 4 Other Methods ............................. 14 5 A Brief Advertisement for My Approach to State-Based Ver- ification and Specification of Concurrent Systems ....... 16 5.1 The Power of Formal Mathematics ................. 16 5.2Specifying Programs with Mathematical Formulas ........ 17 5.3 TLA .................................
  • Master's Thesis

    Master's Thesis

    FACULTY OF SCIENCE AND TECHNOLOGY MASTER'S THESIS Study programme/specialisation: Computer Science Spring / Autumn semester, 20......19 Open/Confidential Author: ………………………………………… Nicolas Fløysvik (signature of author) Programme coordinator: Hein Meling Supervisor(s): Hein Meling Title of master's thesis: Using domain restricted types to improve code correctness Credits: 30 Keywords: Domain restrictions, Formal specifications, Number of pages: …………………75 symbolic execution, Rolsyn analyzer, + supplemental material/other: …………0 Stavanger,……………………….15/06/2019 date/year Title page for Master's Thesis Faculty of Science and Technology Domain Restricted Types for Improved Code Correctness Nicolas Fløysvik University of Stavanger Supervised by: Professor Hein Meling University of Stavanger June 2019 Abstract ReDi is a new static analysis tool for improving code correctness. It targets the C# language and is a .NET Roslyn live analyzer providing live analysis feedback to the developers using it. ReDi uses principles from formal specification and symbolic execution to implement methods for performing domain restriction on variables, parameters, and return values. A domain restriction is an invariant implemented as a check function, that can be applied to variables utilizing an annotation referring to the check method. ReDi can also help to prevent runtime exceptions caused by null pointers. ReDi can prevent null exceptions by integrating nullability into the domain of the variables, making it feasible for ReDi to statically keep track of null, and de- tecting variables that may be null when used. ReDi shows promising results with finding inconsistencies and faults in some programming projects, the open source CoreWiki project by Jeff Fritz and several web service API projects for services offered by Innovation Norway.
  • HOW to THINK ABOUT ALGORITHMS Loop Invariants and Recursion

    HOW to THINK ABOUT ALGORITHMS Loop Invariants and Recursion

    P1: KAE Gutter margin: 7/8 Top margin: 3/8 CUUS154-FM CUUS154-Edmonds 978 0 521 84931 9 February 1, 2008 13:47 HOW TO THINK ABOUT ALGORITHMS Loop Invariants and Recursion There are many algorithm texts that provide lots of well-polished code and proofs of correctness. Instead, this one presents insights, notations, and analogies to help the novice describe and think about algorithms like an expert. It is a bit like a carpenter studying hammers instead of houses. I provide both the big picture and easy step-by-step methods for develop- ing algorithms, while avoiding the comon pitfalls. Paradigms like loop in- variants and recursion help to unify a huge range of algorithms into a few meta-algorithms. Part of the goal is to teach the students to think abstractly. Without getting bogged down in formal proofs, a deeper understanding is fostered so that how and why each algorithm works is transparent. These insights are presented in a slow and clear manner accessible to any second- or third-year student of computer science, preparing him to find on his own innovative ways to solve problems. The study of algorithms forms a core course in every computer science program. However, different schools need different approaches. Institutes of technology encourage the students to be able to use algorithms as black boxes. Engineering schools push an encyclopedia of different algorithms with only the most superficial understandnig of the underlying principles and why the algorithms work. Ivy League computer sceince schools focus on a mathematical formalism beyond the abilities of most students.