The Turing programming language: design and definition
The Turing programming language: design and definition
Dimensions of object-based language design
OOPSLA '87 Conference proceedings on Object-oriented programming systems, languages and applications
POPL '88 Proceedings of the 15th ACM SIGPLAN-SIGACT symposium on Principles of programming languages
Pointer-induced aliasing: a problem classification
POPL '91 Proceedings of the 18th ACM SIGPLAN-SIGACT symposium on Principles of programming languages
Copying and Swapping: Influences on the Design of Reusable Software Components
IEEE Transactions on Software Engineering
Making pure object-oriented languages practical
OOPSLA '91 Conference proceedings on Object-oriented programming systems, languages, and applications
Islands: aliasing protection in object-oriented languages
OOPSLA '91 Conference proceedings on Object-oriented programming systems, languages, and applications
The Geneva convention on the treatment of object aliasing
ACM SIGPLAN OOPS Messenger
Object-Oriented Software Construction
Object-Oriented Software Construction
Capsules and Types in Fresco: Program Verification in Smalltalk
ECOOP '91 Proceedings of the European Conference on Object-Oriented Programming
Modeling the C++ Object Model, An Application of an Abstract Object Model
ECOOP '91 Proceedings of the European Conference on Object-Oriented Programming
Hi-index | 0.00 |
Aliasing has been a problem in both formal verification and practical programming for a number of years. To the formalist, it can be annoyingly difficult to prove the simple Hoare formula {x = true} y := false {x = true}. If x and y refer to the same boolean variable, i.e., x and y are aliased, then the formula will not be valid, and proving that aliasing cannot occur is not always straightforward. To the practicing programmer, aliases can result in mysterious bugs as variables change their values seemingly on their own. A classic example is the matrix multiply routine mult(left, right, result) which puts the product of its first two parameters into the third. This works perfectly well until the day some unsuspecting programmer writes the very reasonable statement mult(a, b, a). If the implementor of the routine did not consider the possibility that an argument may be aliased with the result, disaster is inevitable.