DOCSLIB.ORG

Algebraic Specifications

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Algebraic Specifications Algebraic specifications Dr. Constantinos Constantinides, P.Eng. Department of Computer Science and Software Engineering Concordia University Montreal, Canada 7 January, 2020 1/101 Types ◮ A type is a collection of values. ◮ Examples of types include the integer or the Boolean type. ◮ We can distinguish between simple types and composite (or aggregate) types based on whether or not the values of a type can contain subparts. ◮ As an example, we can say that the integer type is simple, whereas a student record is a composite data type. ◮ A data item is an instance (also: a member) of a type. 2/101 Abstract data types ◮ An abstract data type (ADT) is a mathematical model: A definition for a type solely in terms of the set of values and a set of operations on that type. ◮ The behavior of each operation is determined by its inputs and outputs. ◮ This implies that an ADT is implementation-independent. 3/101 Data types (or concrete data types) ◮ A (concrete) data type is the concrete description of how an ADT is actually implemented. ◮ For example in int x = 7;, we instruct the compiler about the type of variable x (and implicitly about the legal operations as well as about its range of values). 4/101 ADTs and data structures ◮ Do not confuse ADTs with data structures. The former are abstract definitions solely in terms of interfaces, whereas the latter are particular ways of storing and organizing data. ◮ Data structures can be deployed in order to define ADT’s. 5/101 Formal specifications and algebraic specifications ◮ A formal specification is a mathematical description of software system. ◮ It describes what the system should do, but not necessarily how it should do it. ◮ An algebraic specification is a technique that supports the specification of a system through its representation as a collection of sets together with a description of operations on the sets. 6/101 Formal specifications and algebraic specifications /cont. ◮ This aligns with the notion of an abstract data type. ◮ Each specification has a name (with an optional generic parameter list) and a body. ◮ Generic parameters allow abstract types which are collections of other types (such as lists and stacks) to be specified without committing to a particular type of the elements in the collection. 7/101 Abstraction: Interfaces and information hiding ◮ Clients of a system need to know what services a system provides (i.e. what operations are provided by the interface of the system). ◮ Implementors may provide an initial implementation which they can subsequently modify in order to improve performance or other non-functional requirement. 8/101 Specification template ◮ A specification consists of five parts: 1. A declaration of the sort (type) of the entity to be specified and possibly an import of other specifications to be reused in the current specification. 2. Informal description of its operations. 3. Signatures of operations (syntax). 4. Variables (to be used in axioms). 5. Axioms: Statements (rules) that must always hold (semantics: meaning of operations). 9/101 Operations on ADTs ◮ Operations can be classified into the following: ◮ Primitive constructors take no arguments and create objects of the underlying abstract data type. ◮ Non-primitive constructors take arguments and create objects. ◮ Mutators access an object in order to write. ◮ Observers access an object in order to read. 10/101 Example: The Boolean ADT Declaration of the sort and signatures of operations Spec: Boolean; Sort: Boolean; Operations: true → Boolean; false → Boolean; not : Boolean → Boolean; and : Boolean × Boolean → Boolean; or : Boolean × Boolean → Boolean; impl : Boolean × Boolean → Boolean; bicond : Boolean × Boolean → Boolean; ◮ Signatures tell us how to form complex terms from primitive operations. 11/101 Axioms on ADTs ◮ Axioms specify the semantics (meaning) of the ADT, and they characterize its behavior. ◮ They are specified using the operations defined in the signature part. ◮ As a rule of thumb, we write an axiom for each inspection operation over each constructor or mutator operation. 12/101 Axioms on ADTs /cont. ◮ The specification may also include exceptions that define conditions under which the axioms do not hold. ◮ This can be done either by using undefined as the output of certain axioms (indicating that the evaluation of the operation results in an error), or by using an exceptions clause in the specification. 13/101 Example: The Boolean ADT: Variables and axioms Variables: x, y: Boolean; Axioms: [A1] not(true)= false; [A2] not(false) = true; [A3] false and x = false; [A4] true and x = x; [A5] true or x = true; [A6] false or x = x; [A7] x or y = y or x; [A8] x and y = y and x; [A9] not (x and y) = (not x) or (not y); [A10] not (x or y) = (not x) and (not y); [A11] x impl y = not(x) or y; [A12] x bicond y = (x impl y) and (y impl x); 14/101 Example: The Boolean ADT Discussion on Axioms ◮ Axioms A7 and A8 capture the commutativity of conjunction and disjunction respectively: ◮ xory=yorx: (x ∨ y) ⊢ (y ∨ x) , and ◮ xandy=yandx: (x ∧ y) ⊢ (y ∧ x) 15/101 Example: The Boolean ADT Discussion on Axioms /cont. ◮ Axioms A9 and A10 capture De Morgan’s Laws: ◮ not (x and y) = (not x) or (not y) : ¬(x ∧ y) ⊢ (¬x ∨¬y), and ◮ not (x or y) = (not x) and (not y) : ¬(x ∨ y) ⊢ (¬x ∧¬y) 16/101 Example: The set of natural numbers Declaration of the sort Spec: Natural; Sort: Nat; Imports: Boolean; 17/101 Example: The set of natural numbers Informal description of operations Description: Operations on natural numbers include succ which returns the successor number, and add which adds two natural numbers. 18/101 Example: The set of natural numbers Signatures of operations Operations: zero → Nat; iszero : Nat → Boolean; succ : Nat → Nat; add : Nat × Nat → Nat; 19/101 Signatures of operations ◮ For variables x, y : Nat, the following terms are legal: ◮ iszero(succ(x)) ◮ add(succ(x), y) ◮ The following term is not legal ◮ succ(iszero(x)) 20/101 Example: The set of natural numbers Variables and axioms Variables: x, y : Nat; Axioms: [A1] iszero(succ(x)) = false; [A2] add(zero, x) = x; [A3] add(succ(x), y) = add(x, succ(y)); 21/101 Example: The Set ADT ◮ Consider the ADT Set. ◮ Since a set can hold a collection of elements of any type, we will include a generic parameter Element in the specification. 22/101 Example: The Set ADT Declaration of the sort Spec: Set (Element); Sort: Set; Imports: Boolean, N0; 23/101 Example: The Set ADT Description of operations ◮ newset creates an empty set. ◮ add (Set, Element) adds Element into Set. ◮ remove (Set, Element) removes Element from Set. ◮ size(Set) returns the number of elements in Set. ◮ isempty(Set) returns true if Set contains no elements and it returns false otherwise. ◮ ismember(Set, Element) returns true if Element is a member of Set and it returns false otherwise. 24/101 Example: The Set ADT Signatures of operations Operations: newset → Set; add : Set × Element → Set; remove : Set × Element → Set; size : Set → N0; isempty : Set → Boolean; ismember : Set × Element → Boolean; 25/101 Example: The Set ADT Variables and axioms Variables: s: Set; x, y: Element; Axioms: [A1] isempty(newset) = true; [A2] ismember(newset, x) = false; [A3] ismember(add(s, x), x) = true; 26/101 Example: The Set ADT Axioms /cont. The axiom [A1] isempty(newset) = true; can be also captured by size(newset) = 0; 27/101 Example: The Set ADT Axioms /cont. ◮ The axiom [A4] add(add(s, x), y) = add(add(s, y), x) ensures that the order is not important in sets. 28/101 Example: The Set ADT Axioms /cont. ◮ The axiom [A5] size(add(add(newset, x), x)) = 1 ensures that no repetitions are allowed. ◮ An alternative axiom would be add(add(newset, x), x) = add(newset, x) 29/101 Example: The Set ADT Axioms /cont. [A6] size(add(s, x)) = if (not(ismember(s, x))) then size(s) + 1 else size(s); 30/101 This slide is left empty. 31/101 Example: The Set ADT Axioms are universally quantified ◮ Note that we interpret each axiom as being universally quantified by all variables appearing in it. ◮ For example, the axiom [A3] ismember(add(s, x), x) = true; is an abbreviation of ∀(s : Set, x : Element) | ismember(add(s, x), x)= true; 32/101 Example: String Declaration of the sort Spec: String; Sort: String; Imports: Char, N0, Boolean; 33/101 Example: String Description of operations Description: Operation new creates an empty string, append concatenates two strings, add places a character at the end of a string, length returns the size of the string, isempty returns true if the string is empty and it returns false otherwise, and equal compares two strings for equality. 34/101 Example: String Signatures of operations Operations: new → String; append : String × String → String; add : String × Char → String; length : String → N0; isempty : String → Boolean; equal : String × String → Boolean; 35/101 Example: String Variables and axioms Variables: x, y, z: String; c: Char; Axioms: [A1] isempty(new) = true; [A2] length(new) = 0; [A3] isempty(add(x, c)) = false; [A4] length(add(x, c)) = length(x) + 1; [A5] append(x, new) = x; [A6] append(x, add(y, c)) = add(append(x, y), c); [A7] equal(new, new) = true; [A8] equal(new, add(new, c)) = false; 36/101 Example: Array Declaration of the sort Spec: Array (Element); Sort: Array; Imports: N; 37/101 Example: Array Description of operations Description: ◮ Arrays are collections of elements of generic type Element. They have a lower and an upper bound returned by operations first and last. ◮ Individual elements are accessed by their numeric indices. ◮ Operation create takes a lower and an upper bound parameter and constructs an array, initializing its values to undefined.
Load more

Recommended publications
  • A Hybrid Static Type Inference Framework with Neural
    HiTyper: A Hybrid Static Type Inference Framework with Neural Prediction Yun Peng Zongjie Li Cuiyun Gao∗ The Chinese University of Hong Kong Harbin Institute of Technology Harbin Institute of Technology Hong Kong, China Shenzhen, China Shenzhen, China [email protected] [email protected] [email protected] Bowei Gao David Lo Michael Lyu Harbin Institute of Technology Singapore Management University The Chinese University of Hong Kong Shenzhen, China Singapore Hong Kong, China [email protected] [email protected] [email protected] ABSTRACT also supports type annotations in the Python Enhancement Pro- Type inference for dynamic programming languages is an impor- posals (PEP) [21, 22, 39, 43]. tant yet challenging task. By leveraging the natural language in- Type prediction is a popular task performed by most attempts. formation of existing human annotations, deep neural networks Traditional static type inference techniques [4, 9, 14, 17, 36] and outperform other traditional techniques and become the state-of- type inference tools such as Pytype [34], Pysonar2 [33], and Pyre the-art (SOTA) in this task. However, they are facing some new Infer [31] can predict sound results for the variables with enough challenges, such as fixed type set, type drift, type correctness, and static constraints, e.g., a = 1, but are unable to handle the vari- composite type prediction. ables with few static constraints, e.g. most function arguments. To mitigate the challenges, in this paper, we propose a hybrid On the other hand, dynamic type inference techniques [3, 37] and type inference framework named HiTyper, which integrates static type checkers simulate the workflow of functions and solve types inference into deep learning (DL) models for more accurate type according to input cases and typing rules.
    [Show full text]
  • ACDT: Architected Composite Data Types Trading-In Unfettered Data Access for Improved Execution
    ACDT: Architected Composite Data Types Trading-in Unfettered Data Access for Improved Execution Andres Marquez∗, Joseph Manzano∗, Shuaiwen Leon Song∗, Benoˆıt Meistery Sunil Shresthaz, Thomas St. Johnz and Guang Gaoz ∗Pacific Northwest National Laboratory fandres.marquez,joseph.manzano,[email protected] yReservoir Labs [email protected] zUniversity of Delaware fshrestha,stjohn,[email protected] Abstract— reduction approaches associated with improved data locality, obtained through optimized data and computation distribution. With Exascale performance and its challenges in mind, one ubiquitous concern among architects is energy efficiency. In the SW-stack we foresee the runtime system to have a Petascale systems projected to Exascale systems are unsustainable particular important role to contribute to the solution of the at current power consumption rates. One major contributor power challenge. It is here where the massive concurrency is to system-wide power consumption is the number of memory managed and where judicious data layouts [11] and data move- operations leading to data movement and management techniques ments are orchestrated. With that in mind, we set to investigate applied by the runtime system. To address this problem, we on how to improve efficiency of a massively multithreaded present the concept of the Architected Composite Data Types adaptive runtime system in managing and moving data, and the (ACDT) framework. The framework is made aware of data trade-offs an improved data management efficiency requires. composites, assigning them a specific layout, transformations Specifically, in the context of run-time system (RTS), we and operators. Data manipulation overhead is amortized over a explore the power efficiency potential that data compression larger number of elements and program performance and power efficiency can be significantly improved.
    [Show full text]
  • Evaluating Variability Modeling Techniques for Supporting Cyber-Physical System Product Line Engineering
    This paper will be presented at System Analysis and Modeling (SAM) Conference 2016 (http://sdl-forum.org/Events/SAM2016/index.htm) Evaluating Variability Modeling Techniques for Supporting Cyber-Physical System Product Line Engineering Safdar Aqeel Safdar 1, Tao Yue1,2, Shaukat Ali1, Hong Lu1 1Simula Research Laboratory, Oslo, Norway 2 University of Oslo, Oslo, Norway {safdar, tao, shaukat, honglu}@simula.no Abstract. Modern society is increasingly dependent on Cyber-Physical Systems (CPSs) in diverse domains such as aerospace, energy and healthcare. Employing Product Line Engineering (PLE) in CPSs is cost-effective in terms of reducing production cost, and achieving high productivity of a CPS development process as well as higher quality of produced CPSs. To apply CPS PLE in practice, one needs to first select an appropriate variability modeling technique (VMT), with which variabilities of a CPS Product Line (PL) can be specified. In this paper, we proposed a set of basic and CPS-specific variation point (VP) types and modeling requirements for proposing CPS-specific VMTs. Based on the proposed set of VP types (basic and CPS-specific) and modeling requirements, we evaluated four VMTs: Feature Modeling, Cardinality Based Feature Modeling, Common Variability Language, and SimPL (a variability modeling technique dedicated to CPS PLE), with a real-world case study. Evaluation results show that none of the selected VMTs can capture all the basic and CPS-specific VP and meet all the modeling requirements. Therefore, there is a need to extend existing techniques or propose new ones to satisfy all the requirements. Keywords: Product Line Engineering, Variability Modeling, and Cyber- Physical Systems 1 Introduction Cyber-Physical Systems (CPSs) integrate computation and physical processes and their embedded computers and networks monitor and control physical processes by often relying on closed feedback loops [1, 2].
    [Show full text]
  • UML Profile for Communicating Systems a New UML Profile for the Specification and Description of Internet Communication and Signaling Protocols
    UML Profile for Communicating Systems A New UML Profile for the Specification and Description of Internet Communication and Signaling Protocols Dissertation zur Erlangung des Doktorgrades der Mathematisch-Naturwissenschaftlichen Fakultäten der Georg-August-Universität zu Göttingen vorgelegt von Constantin Werner aus Salzgitter-Bad Göttingen 2006 D7 Referent: Prof. Dr. Dieter Hogrefe Korreferent: Prof. Dr. Jens Grabowski Tag der mündlichen Prüfung: 30.10.2006 ii Abstract This thesis presents a new Unified Modeling Language 2 (UML) profile for communicating systems. It is developed for the unambiguous, executable specification and description of communication and signaling protocols for the Internet. This profile allows to analyze, simulate and validate a communication protocol specification in the UML before its implementation. This profile is driven by the experience and intelligibility of the Specification and Description Language (SDL) for telecommunication protocol engineering. However, as shown in this thesis, SDL is not optimally suited for specifying communication protocols for the Internet due to their diverse nature. Therefore, this profile features new high-level language concepts rendering the specification and description of Internet protocols more intuitively while abstracting from concrete implementation issues. Due to its support of several concrete notations, this profile is designed to work with a number of UML compliant modeling tools. In contrast to other proposals, this profile binds the informal UML semantics with many semantic variation points by defining formal constraints for the profile definition and providing a mapping specification to SDL by the Object Constraint Language. In addition, the profile incorporates extension points to enable mappings to many formal description languages including SDL. To demonstrate the usability of the profile, a case study of a concrete Internet signaling protocol is presented.
    [Show full text]
  • Data Types and Variables
    Color profile: Generic CMYK printer profile Composite Default screen Complete Reference / Visual Basic 2005: The Complete Reference / Petrusha / 226033-5 / Chapter 2 2 Data Types and Variables his chapter will begin by examining the intrinsic data types supported by Visual Basic and relating them to their corresponding types available in the .NET Framework’s Common TType System. It will then examine the ways in which variables are declared in Visual Basic and discuss variable scope, visibility, and lifetime. The chapter will conclude with a discussion of boxing and unboxing (that is, of converting between value types and reference types). Visual Basic Data Types At the center of any development or runtime environment, including Visual Basic and the .NET Common Language Runtime (CLR), is a type system. An individual type consists of the following two items: • A set of values. • A set of rules to convert every value not in the type into a value in the type. (For these rules, see Appendix F.) Of course, every value of another type cannot always be converted to a value of the type; one of the more common rules in this case is to throw an InvalidCastException, indicating that conversion is not possible. Scalar or primitive types are types that contain a single value. Visual Basic 2005 supports two basic kinds of scalar or primitive data types: structured data types and reference data types. All data types are inherited from either of two basic types in the .NET Framework Class Library. Reference types are derived from System.Object. Structured data types are derived from the System.ValueType class, which in turn is derived from the System.Object class.
    [Show full text]
  • DRAFT1.2 Methods
    HL7 v3.0 Data Types Specification - Version 0.9 Table of Contents Abstract . 1 1 Introduction . 2 1.1 Goals . 3 DRAFT1.2 Methods . 6 1.2.1 Analysis of Semantic Fields . 7 1.2.2 Form of Data Type Definitions . 10 1.2.3 Generalized Types . 11 1.2.4 Generic Types . 12 1.2.5 Collections . 15 1.2.6 The Meta Model . 18 1.2.7 Implicit Type Conversion . 22 1.2.8 Literals . 26 1.2.9 Instance Notation . 26 1.2.10 Typus typorum: Boolean . 28 1.2.11 Incomplete Information . 31 1.2.12 Update Semantics . 33 2 Text . 36 2.1 Introduction . 36 2.1.1 From Characters to Strings . 36 2.1.2 Display Properties . 37 2.1.3 Encoding of appearance . 37 2.1.4 From appearance of text to multimedial information . 39 2.1.5 Pulling the pieces together . 40 2.2 Character String . 40 2.2.1 The Unicode . 41 2.2.2 No Escape Sequences . 42 2.2.3 ITS Responsibilities . 42 2.2.4 HL7 Applications are "Black Boxes" . 43 2.2.5 No Penalty for Legacy Systems . 44 2.2.6 Unicode and XML . 47 2.3 Free Text . 47 2.3.1 Multimedia Enabled Free Text . 48 2.3.2 Binary Data . 55 2.3.3 Outstanding Issues . 57 3 Things, Concepts, and Qualities . 58 3.1 Overview of the Problem Space . 58 3.1.1 Concept vs. Instance . 58 3.1.2 Real World vs. Artificial Technical World . 59 3.1.3 Segmentation of the Semantic Field .
    [Show full text]
  • Csci 555: Functional Programming Functional Programming in Scala Functional Data Structures
    CSci 555: Functional Programming Functional Programming in Scala Functional Data Structures H. Conrad Cunningham 6 March 2019 Contents 3 Functional Data Structures 2 3.1 Introduction . .2 3.2 A List algebraic data type . .2 3.2.1 Algebraic data types . .2 3.2.2 ADT confusion . .3 3.2.3 Using a Scala trait . .3 3.2.3.1 Aside on Haskell . .4 3.2.4 Polymorphism . .4 3.2.5 Variance . .5 3.2.5.1 Covariance and contravariance . .5 3.2.5.2 Function subtypes . .6 3.2.6 Defining functions in companion object . .7 3.2.7 Function to sum a list . .7 3.2.8 Function to multiply a list . .9 3.2.9 Function to remove adjacent duplicates . .9 3.2.10 Variadic function apply ................... 11 3.3 Data sharing . 11 3.3.1 Function to take tail of list . 12 3.3.2 Function to drop from beginning of list . 13 3.3.3 Function to append lists . 14 3.4 Other list functions . 15 3.4.1 Tail recursive function reverse . 15 3.4.2 Higher-order function dropWhile . 17 3.4.3 Curried function dropWhile . 17 3.5 Generalizing to Higher Order Functions . 18 3.5.1 Fold Right . 18 3.5.2 Fold Left . 22 3.5.3 Map . 23 1 3.5.4 Filter . 25 3.5.5 Flat Map . 26 3.6 Classic algorithms on lists . 27 3.6.1 Insertion sort and bounded generics . 27 3.6.2 Merge sort . 29 3.7 Lists in the Scala standard library .
    [Show full text]
  • Ata Lements for Mergency Epartment Ystems
    D ata E lements for E mergency D epartment S ystems Release 1.0 U.S. DEPARTMENT OF HEALTH AND HUMAN SERVICES CDCCENTERS FOR DISEASE CONTROL AND PREVENTION D ata E lements for E mergency D epartment S ystems Release 1.0 National Center for Injury Prevention and Control Atlanta, Georgia 1997 Data Elements for Emergency Department Systems, Release 1.0 (DEEDS) is the result of contributions by participants in the National Workshop on Emergency Department Data, held January 23-25, 1996, in Atlanta, Georgia, subsequent review and comment by individuals who read Release 1.0 in draft form, and finalization by a multidisciplinary writing committee. DEEDS is a set of recommendations published by the National Center for Injury Prevention and Control of the Centers for Disease Control and Prevention: Centers for Disease Control and Prevention David Satcher, MD, PhD, Director National Center for Injury Prevention and Control Mark L. Rosenberg, MD, MPP, Director Division of Acute Care, Rehabilitation Research, and Disability Prevention Richard J. Waxweiler, PhD, Director Acute Care Team Daniel A. Pollock, MD, Leader Production services were provided by the staff of the Office of Communication Resources, National Center for Injury Prevention and Control, and the Management Analysis and Services Office: Editing Valerie R. Johnson Cover Design and Layout Barbara B. Lord Use of trade names is for identification only and does not constitute endorsement by the U.S. Department of Health and Human Services. This document and subsequent revisions can be found at the National Center for Injury Prevention and Control Web site: http://www.cdc.gov/ncipc/pub-res/deedspage.htm Suggested Citation: National Center for Injury Prevention and Control.
    [Show full text]
  • Fundamental Programming Concepts
    APPENDIX A Fundamental Programming Concepts The following information is for readers who are new to programming and need a primer on some fundamental programming concepts. If you have programmed in another language, chances are the concepts presented in this appendix are not new to you. You should, however, review the material briefly to become familiar with the C# syntax. Working with Variables and Data Types Variables in programming languages store values that can change while the program executes. For example, if you wanted to count the number of times a user tries to log in to an application, you could use a variable to track the number of attempts. A variable is a memory location where a value is stored. Using the variable, your program can read or alter the value stored in memory. Before you use a variable in your program, however, you must declare it. When you declare a variable, the compiler also needs to know what kind of data will be stored at the memory location. For example, will it be numbers or letters? If the variable will store numbers, how large can a number be? Will the variable store decimals or only whole numbers? You answer these questions by assigning a data type to the variable. A login counter, for example, only needs to hold positive whole numbers. The following code demonstrates how you declare a variable named counter in C# with an integer data type: int counter; Specifying the data type is referred to as strong typing. Strong typing results in more efficient memory management, faster execution, and compiler type checking, all of which reduces runtime errors.
    [Show full text]
  • (Paper 3. Sec 3.1) Data Representation with Majid Tahir
    Computer Science 9608 (Paper 3. Sec 3.1) Data Representation with Majid Tahir Syllabus Content: 3.1 Data representation 3.1.1 User-defined data types why user-defined types are necessary, define and use non-composite types: enumerated, pointer define and use composite data types: set, record and class/object choose and design an appropriate user-defined data type for a given problem User defined Data Type You have already met a variety of built-in data types with integers, strings, chars and more. But often these limited data types aren't enough and a programmer wants to build their own data types. Just as an integer is restricted to "a whole number from - 2,147,483,648 through 2,147,483,647", user-defined data types have limits placed on their use by the programmer. A user defined data type is a feature in most high level programming languages which allows a user (programmer) to define data type according to his/her own requirements There are two categories of user defined data types.: 1. Non-composite data type a. Enumerated data type b. Pointer data type 2. Composite a. Record data type b. Set data type c. Objects and classes Non-composite user-defined data type: A non-composite data type is defined without referencing another data type. They don’t combine different built-in data types in one data type. Non-Composite data types are: www.majidtahir.com Contact: +923004003666 Email: [email protected] 1 Computer Science 9608 (Paper 3. Sec 3.1) Data Representation with Majid Tahir Enumerated data type Pointers An enumerated data type defines a list of possible values.
    [Show full text]
  • Fast Run-Time Type Checking of Unsafe Code
    Fast Run-time Type Checking of Unsafe Code Stephen Kell Computer Laboratory, University of Cambridge 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom fi[email protected] Abstract In return, unsafe languages offer several benefits: avoid- Existing approaches for detecting type errors in unsafe lan- ance of certain run-time overheads; a wide range of possi- guages work by changing the toolchain’s source- and/or ble optimisations; enough control of binary interfaces for binary-level contracts, or by imposing up-front proof obli- efficient communication with the operating system or re- gations. While these techniques permit some degree of mote processes. These are valid trades, but have so far come compile-time checking, they hinder use of libraries and are at a high price: of having no machine-assisted checking of not amenable to gradual adoption. This paper describes type- or memory-correctness beyond the limited efforts of libcrunch, a system for binary-compatible run-time type the compiler. Various tools have been developed to offer checking of unmodified unsafe code using a simple yet flex- stronger checks, but have invariably done so by abandon- ible language-independent design. Using a series of experi- ing one or more of unsafe languages’ strengths. Existing dy- ments and case studies, we show our prototype implemen- namic analyses [Burrows et al. 2003; ?] offer high run-time tation to have acceptably low run-time overhead , and to be overhead, while tools based on conservative static analy- easily applicable to real applications written in C without ses [?] are unduly restrictive. Hybrid static/dynamic systems source-level modification.
    [Show full text]
  • Datapath for Buildgates Synthesis and Cadence PKS
    Datapath for BuildGates Synthesis and Cadence PKS Product Version 5.0.13 December 2003 2000-2003 Cadence Design Systems, Inc. All rights reserved. Printed in the United States of America. Cadence Design Systems, Inc., 555 River Oaks Parkway, San Jose, CA 95134, USA Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. (Cadence) contained in this document are attributed to Cadence with the appropriate symbol. For queries regarding Cadence’s trademarks, contact the corporate legal department at the address shown above or call 1-800-862-4522. All other trademarks are the property of their respective holders. Restricted Print Permission: This publication is protected by copyright and any unauthorized use of this publication may violate copyright, trademark, and other laws. Except as specified in this permission statement, this publication may not be copied, reproduced, modified, published, uploaded, posted, transmitted, or distributed in any way, without prior written permission from Cadence. This statement grants you permission to print one (1) hard copy of this publication subject to the following conditions: 1. The publication may be used solely for personal, informational, and noncommercial purposes; 2. The publication may not be modified in any way; 3. Any copy of the publication or portion thereof must include all original copyright, trademark, and other proprietary notices and this permission statement; and 4. Cadence reserves the right to revoke this authorization at any time, and any such use shall be discontinued immediately upon written notice from Cadence. Disclaimer: Information in this publication is subject to change without notice and does not represent a commitment on the part of Cadence.
    [Show full text]