Results 1 - 10
of
356
An axiomatic basis for computer programming
- COMMUNICATIONS OF THE ACM
, 1969
"... In this paper an attempt is made to explore the logical founda-tions of computer programming by use of techniques which were first applied in the study of geometry and have later been extended to other branches of mathematics. This in-volves the elucidation of sets of axioms and rules of inference w ..."
Abstract
-
Cited by 1221 (4 self)
- Add to MetaCart
In this paper an attempt is made to explore the logical founda-tions of computer programming by use of techniques which were first applied in the study of geometry and have later been extended to other branches of mathematics. This in-volves the elucidation of sets of axioms and rules of inference which can be used in proofs of the properties of computer programs. Examples are given of such axioms and rules, and a formal proof of a simple theorem is displayed. Finally, it is argued that important advantages, both theoretical and prac-tical, may follow from a pursuance of these topics.
Proof-Carrying Code
, 1997
"... This paper describes proof-carrying code (PCC), a mechanism by which a host system can determine with certainty thatitissafetoexecute a program supplied (possibly in binary form) by anuntrusted source. For this to be possible, the untrusted code producer must supply with the code a safety proof that ..."
Abstract
-
Cited by 1016 (24 self)
- Add to MetaCart
This paper describes proof-carrying code (PCC), a mechanism by which a host system can determine with certainty thatitissafetoexecute a program supplied (possibly in binary form) by anuntrusted source. For this to be possible, the untrusted code producer must supply with the code a safety proof that attests to the code's adherence to a previously de ned safety policy. The host can then easily and quickly validate the proof without using cryptography and without consulting any external agents. In order to gain preliminary experience with PCC, we have performed several case studies. We showinthis paper how proof-carrying code mightbeusedtodevelop safe assembly-language extensions of ML programs. In the context of this case study, we present and prove the adequacy of concrete representations for the safety policy, the safety proofs, and the proof validation. Finally, we brie y discuss how we use proof-carrying code to develop network packet lters that are faster than similar lters developed using other techniques and are formally guaranteed to be safe with respect to a given operating system safety policy.
Dynamic Logic
- Handbook of Philosophical Logic
, 1984
"... ed to be true under the valuation u iff there exists an a 2 N such that the formula x = y is true under the valuation u[x=a], where u[x=a] agrees with u everywhere except x, on which it takes the value a. This definition involves a metalogical operation that produces u[x=a] from u for all possibl ..."
Abstract
-
Cited by 743 (8 self)
- Add to MetaCart
ed to be true under the valuation u iff there exists an a 2 N such that the formula x = y is true under the valuation u[x=a], where u[x=a] agrees with u everywhere except x, on which it takes the value a. This definition involves a metalogical operation that produces u[x=a] from u for all possible values a 2 N. This operation becomes explicit in DL in the form of the program x := ?, called a nondeterministic or wildcard assignment. This is a rather unconventional program, since it is not effective; however, it is quite useful as a descriptive tool. A more conventional way to obtain a square root of y, if it exists, would be the program x := 0 ; while x < y do x := x + 1: (1) In DL, such programs are first-class objects on a par with formulas, complete with a collection of operators for forming compound programs inductively from a basis of primitive programs. To discuss the effect of the execution of a program on the truth of a formula ', DL uses a modal construct <>', which
The Spec# Programming System: An Overview
, 2004
"... Spec# is the latest in a long line of work on programming languages and systems aimed at improving the development of correct software. This paper describes the goals and architecture of the Spec# programming system, consisting of the object-oriented Spec# programming language, the Spec# compiler ..."
Abstract
-
Cited by 381 (45 self)
- Add to MetaCart
Spec# is the latest in a long line of work on programming languages and systems aimed at improving the development of correct software. This paper describes the goals and architecture of the Spec# programming system, consisting of the object-oriented Spec# programming language, the Spec# compiler, and the Boogie static program verifier. The language includes constructs for writing specifications that capture programmer intentions about how methods and data are to be used, the compiler emits run-time checks to enforce these specifications, and the verifier can check the consistency between a program and its specifications. The Spec#
Checking system rules using system-specific, programmer-written compiler extensions
, 2000
"... ..."
Proving the Correctness of Multiprocess Programs
, 1977
"... The inductive assertion method is generalized to permit formal, machine-verifiable proofs of correctness for multiprocess programs. Individual processes are represented by ordinary flowcharts, and no special synchronization mechanisms are assumed, so the method can be applied to a large class of mul ..."
Abstract
-
Cited by 274 (20 self)
- Add to MetaCart
The inductive assertion method is generalized to permit formal, machine-verifiable proofs of correctness for multiprocess programs. Individual processes are represented by ordinary flowcharts, and no special synchronization mechanisms are assumed, so the method can be applied to a large class of multiprocess programs. A correctness proof can be designed together with the program by a hierarchical process of stepwise refinement, making the method practical for larger programs. The resulting proofs tend to be natural formalizations of the informal proofs that are now used.
Definitional interpreters for higher-order programming languages
- Reprinted from the proceedings of the 25th ACM National Conference
, 1972
"... Abstract. Higher-order programming languages (i.e., languages in which procedures or labels can occur as values) are usually defined by interpreters that are themselves written in a programming language based on the lambda calculus (i.e., an applicative language such as pure LISP). Examples include ..."
Abstract
-
Cited by 263 (2 self)
- Add to MetaCart
Abstract. Higher-order programming languages (i.e., languages in which procedures or labels can occur as values) are usually defined by interpreters that are themselves written in a programming language based on the lambda calculus (i.e., an applicative language such as pure LISP). Examples include McCarthy’s definition of LISP, Landin’s SECD machine, the Vienna definition of PL/I, Reynolds ’ definitions of GEDANKEN, and recent unpublished work by L. Morris and C. Wadsworth. Such definitions can be classified according to whether the interpreter contains higher-order functions, and whether the order of application (i.e., call by value versus call by name) in the defined language depends upon the order of application in the defining language. As an example, we consider the definition of a simple applicative programming language by means of an interpreter written in a similar language. Definitions in each of the above classifications are derived from one another by informal but constructive methods. The treatment of imperative features such as jumps and assignment is also discussed.
Bugs as Deviant Behavior: A General Approach to Inferring Errors in Systems Code
, 2001
"... A major obstacle to finding program errors in a real system is knowing what correctness rules the system must obey. These rules are often undocumented or specified in an ad hoc manner. This paper demonstrates tech-niques that automatically extract such checking information from the source code itsel ..."
Abstract
-
Cited by 245 (11 self)
- Add to MetaCart
A major obstacle to finding program errors in a real system is knowing what correctness rules the system must obey. These rules are often undocumented or specified in an ad hoc manner. This paper demonstrates tech-niques that automatically extract such checking information from the source code itself, rather than the programmer, thereby avoiding the need for a priori knowledge of system rules. The cornerstone of our approach is inferring programmer "beliefs" that we then cross-check for contradictions. Beliefs are facts implied by code: a dereference of a pointer, p, implies a belief that p is non-null, a call to "unlock(1)" implies that 1 was locked, etc. For beliefs we know the programmer must hold, such as the pointer dereference above, we immediately flag contra-
A Fast Mutual Exclusion Algorithm
, 1986
"... A new solution to the mutual exclusion problem is presented that, in the absence of contention, requires only seven memory accesses. It assumes atomic reads and atomic writes to shared registers. Capsule Review To build a useful computing system from a collection of processors that communicate by ..."
Abstract
-
Cited by 202 (6 self)
- Add to MetaCart
A new solution to the mutual exclusion problem is presented that, in the absence of contention, requires only seven memory accesses. It assumes atomic reads and atomic writes to shared registers. Capsule Review To build a useful computing system from a collection of processors that communicate by sharing memory, but lack any atomic operation more complex than a memory read or write, it is necessary to implement mutual exclusion using only these operations. Solutions to this problem have been known for twenty years, but they are linear in the number of processors. Lamport presents a new algorithm which takes constant time (five writes and two reads) in the absence of contention, which is the normal case. To achieve this performance it sacrifices fairness, which is probably unimportant in practical applications. The paper gives an informal argument that the algorithm's performance in the absence of contention is optimal, and a fairly formal proof of safety and freedom from deadlock, u...

