Type-safe multithreading in cyclone
Proceedings of the 2003 ACM SIGPLAN international workshop on Types in languages design and implementation
Quantified types in an imperative language
ACM Transactions on Programming Languages and Systems (TOPLAS)
Safe manual memory management in cyclone
Science of Computer Programming - Special issue on five perspectives on modern memory management: Systems, hardware and theory
The transactional memory / garbage collection analogy
Proceedings of the 22nd annual ACM SIGPLAN conference on Object-oriented programming systems and applications
SoftBound: highly compatible and complete spatial memory safety for c
Proceedings of the 2009 ACM SIGPLAN conference on Programming language design and implementation
CETS: compiler enforced temporal safety for C
Proceedings of the 2010 international symposium on Memory management
SAS'06 Proceedings of the 13th international conference on Static Analysis
Hi-index | 0.00 |
Memory safety and type safety are invaluable features for building robust software. However, most safe programming languages are at a high level of memory management. This control is one reason C remains the de facto standard for writing systems software or extending legacy systems already written in C. The Cyclone language aims to bring safety to C-style programming without sacrificing the programmer control necessary for low-level software. A combination of advanced compile-time techniques, run-time checks, and modern language features helps achieve this goal. This dissertation focuses on the advanced compile-time techniques. A type system with quantified types and effects prevents incorrect type casts, dangling-pointer dereferences, and data races. An intraprocedural flow analysis prevents dereferencing NULL pointers and uninitialized memory, and extensions to it can prevent proofs demonstrate that these compile-time techniques are sound: The safety violations they address become impossible. A less formal evaluation establishes two other design goals of equal importance. First, the language remains expressive. Although it rejects some safe programs, it permits many C idioms regarding generic code, manual memory management, lock-based synchronization, NULL-pointer checking, and data initialization. Second, the language represents a unified approach. A small collection of techniques addresses a range of problems, indicating that the problems are more alike than they originally seem.