Results 1 - 10
of
16
Verification of Object-Oriented Programs with Invariants
- JOURNAL OF OBJECT TECHNOLOGY
, 2004
"... ... This paper defines a programming methodology for using object invariants. The methodology, which enriches a program's state space to express when each object invariant holds, deals with owned object components, ownership transfer, and subclassing, and is expressive enough to allow many interesti ..."
Abstract
-
Cited by 173 (36 self)
- Add to MetaCart
... This paper defines a programming methodology for using object invariants. The methodology, which enriches a program's state space to express when each object invariant holds, deals with owned object components, ownership transfer, and subclassing, and is expressive enough to allow many interesting object-oriented programs to be specified and verified. Lending itself to sound modular verification, the methodology also provides a solution to the problem of determining what state a method is allowed to modify.
A Linearly Typed Assembly Language
- In Workshop on Types in Compilation
"... Today's type-safe low-level languages rely on garbage collection to recycle heap-allocated objects safely. We present LTAL, a safe, low-level, yet simple language that "stands on its own": it guarantees safe execution within a fixed memory space, without relying on external run-time support. We demo ..."
Abstract
-
Cited by 136 (35 self)
- Add to MetaCart
Today's type-safe low-level languages rely on garbage collection to recycle heap-allocated objects safely. We present LTAL, a safe, low-level, yet simple language that "stands on its own": it guarantees safe execution within a fixed memory space, without relying on external run-time support. We demonstrate the expressiveness of LTAL by giving a type-preserving compiler for the functional core of ML. But this independence comes at a steep price: LTAL's type system imposes a draconian discipline of linearity that ensures that memory can be reused safely, but prohibits any useful kind of sharing. We present the results of experiments with a prototype LTAL system that show just how high the price of linearity can be.
An Effective Theory of Type Refinements
, 2002
"... We develop an explicit two level system that allows programmers to reason about the behavior of effectful programs. The first level is an ordinary ML-style type system, which confers standard properties on program behavior. The second level is a conservative extension of the first that uses a logic ..."
Abstract
-
Cited by 56 (5 self)
- Add to MetaCart
We develop an explicit two level system that allows programmers to reason about the behavior of effectful programs. The first level is an ordinary ML-style type system, which confers standard properties on program behavior. The second level is a conservative extension of the first that uses a logic of type refinements to check more precise properties of program behavior. Our logic is a fragment of intuitionistic linear logic, which gives programmers the ability to reason locally about changes of program state. We provide a generic resource semantics for our logic as well as a sound, decidable, syntactic refinement-checking system. We also prove that refinements give rise to an optimization principle for programs. Finally, we illustrate the power of our system through a number of examples.
Modular verification of assembly code with stack-based control abstractions
- In PLDI’06
, 2006
"... Runtime stacks are critical components of any modern software— they are used to implement powerful control structures such as function call/return, stack cutting and unwinding, coroutines, and thread context switch. Stack operations, however, are very hard to reason about: there are no known formal ..."
Abstract
-
Cited by 20 (8 self)
- Add to MetaCart
Runtime stacks are critical components of any modern software— they are used to implement powerful control structures such as function call/return, stack cutting and unwinding, coroutines, and thread context switch. Stack operations, however, are very hard to reason about: there are no known formal specifications for certifying C-style setjmp/longjmp, stack cutting and unwinding, or weak continuations (in C--). In many proof-carrying code (PCC) systems, return code pointers and exception handlers are treated as general first-class functions (as in continuation-passing style) even though both should have more limited scopes. In this paper we show that stack-based control abstractions follow a much simpler pattern than general first-class code pointers. We present a simple but flexible Hoare-style framework for modular verification of assembly code with all kinds of stackbased control abstractions, including function call/return, tail call, setjmp/longjmp, weak continuation, stack cutting, stack unwinding, multi-return function call, coroutines, and thread context switch. Instead of presenting a specific logic for each control structure, we develop all reasoning systems as instances of a generic framework. This allows program modules and their proofs developed in different PCC systems to be linked together. Our system is fully mechanized. We give the complete soundness proof and a full verification of several examples in the Coq proof assistant. 1.
Certifying compilation for a language with stack allocation
- In IEEE Symposium on Logic in Computer Science (LICS
, 2005
"... This paper describes an assembly-language type system capable of ensuring memory safety in the presence of both heap and stack allocation. The type system uses linear logic and a set of domain-specific predicates to specify invariants about the shape of the store. Part of the model for our logic is ..."
Abstract
-
Cited by 15 (2 self)
- Add to MetaCart
This paper describes an assembly-language type system capable of ensuring memory safety in the presence of both heap and stack allocation. The type system uses linear logic and a set of domain-specific predicates to specify invariants about the shape of the store. Part of the model for our logic is a tree of “stack tags ” that tracks the evolution of the stack over time. To demonstrate the expressiveness of the type system, we define Micro-CLI, a simple imperative language that captures the essence of stack allocation in the Common Language Infrastructure. We show how to compile welltyped Micro-CLI into well-typed assembly. 1
Low-Level Linear Memory Management
, 2004
"... E#cient low-level systems need more control over memory than safe high-level languages usually provide. As a result, run-time systems are typically written in unsafe languages such as C. This paper extends previous work on linear types, alias types, regions, and typed garbage collection to give type ..."
Abstract
-
Cited by 13 (4 self)
- Add to MetaCart
E#cient low-level systems need more control over memory than safe high-level languages usually provide. As a result, run-time systems are typically written in unsafe languages such as C. This paper extends previous work on linear types, alias types, regions, and typed garbage collection to give type-safe code more control over memory. The approach is truly low-level: memory consists of a single linear array of words, with load and store operations but no built-in notion of an object. The paper constructs lists and arrays out of the basic linear memory primitives, and then introduces type sequences for building regions of nonlinear data. It then describes a Cheney queue typed garbage collector, implemented safely over regions.
Verification of Safety Properties for Concurrent Assembly Code
- IN PROC. 2004 ACM SIGPLAN INT’L CONF. ON FUNCTIONAL PROG
, 2004
"... Concurrency, as a useful feature of many modern programming languages and systems, is generally hard to reason about. Although existing work has explored the verification of concurrent programs using high-level languages and calculi, the verification of concurrent assembly code remains an open probl ..."
Abstract
-
Cited by 13 (6 self)
- Add to MetaCart
Concurrency, as a useful feature of many modern programming languages and systems, is generally hard to reason about. Although existing work has explored the verification of concurrent programs using high-level languages and calculi, the verification of concurrent assembly code remains an open problem, largely due to the lack of abstraction at a low-level. Nevertheless, it is sometimes necessary to reason about assembly code or machine executables so as to achieve higher assurance. In this paper
From Control Effects to Typed Continuation Passing
- In 30th SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL’03
, 2003
"... First-class continuations are a powerful computational effect, allowing the programmer to express any form of jumping. Types and effect systems can be used to reason about continuations, both in the source language and in the target language of the continuation-passing transform. In this paper, we e ..."
Abstract
-
Cited by 13 (1 self)
- Add to MetaCart
First-class continuations are a powerful computational effect, allowing the programmer to express any form of jumping. Types and effect systems can be used to reason about continuations, both in the source language and in the target language of the continuation-passing transform. In this paper, we establish the connection between an effect system for first-class continuations and typed versions of continuationpassing style. A region in the effect system determines a local answer type for continuations, such that the continuation transforms of pure expressions are parametrically polymorphic in their answer types. We use this polymorphism to derive transforms that make use of effect information, in particular, a mixed linear/non-linear continuation-passing transform, in which expressions without control effects are passed their continuations linearly.
ILC: A Foundation for Automated Reasoning About Pointer Programs
, 2005
"... This paper shows how to use Girard’s intuitionistic linear logic extended with arithmetic or other constraints to reason about pointer programs. More specifically, first, the paper defines the proof theory for ILC (Intuitionistic Linear logic with Constraints) and shows it is consistent via a proof ..."
Abstract
-
Cited by 13 (3 self)
- Add to MetaCart
This paper shows how to use Girard’s intuitionistic linear logic extended with arithmetic or other constraints to reason about pointer programs. More specifically, first, the paper defines the proof theory for ILC (Intuitionistic Linear logic with Constraints) and shows it is consistent via a proof of cut elimination. Second, inspired by prior work of O’Hearn, Reynolds and Yang, the paper explains how to interpret linear logical formulas as descriptions of a program store. Third, we define a simple imperative programming language with mutable references and arrays and give verification condition generation rules that produce assertions in ILC. Finally, we identify a fragment of ILC, ILC − , that is both decidable and closed under generation of verification conditions. In other words, if loop invariants are specified in ILC − , then the resulting verification conditions are also in ILC −. Since verification condition generation is syntax-directed, we obtain a decidable procedure for checking properties of pointer programs.
A theory of implementation-dependent low-level software
, 2006
"... We present a theory describing implementation-dependent assumptions that a C program might make, such as the size and alignment of data. We define a static analysis to encode such assumptions in a constraint that describes language implementations (i.e., compilers and architectures) on which a progr ..."
Abstract
-
Cited by 3 (1 self)
- Add to MetaCart
We present a theory describing implementation-dependent assumptions that a C program might make, such as the size and alignment of data. We define a static analysis to encode such assumptions in a constraint that describes language implementations (i.e., compilers and architectures) on which a program is memory-safe. The constraint produced by the analysis is a formula in a theory of first-order logic for which implementations are models. By defining an abstract machine that is parameterized by an implementation, we can prove the analysis sound. This foundation explains some common coding practices and the poorly understood assumptions they are implicitly making.

