The Cyclone programming language is intended to be a safe dialect of the C language. Cyclone is designed to avoid buffer overflows and other vulnerabilities that are possible in C programs, without losing the power and convenience of C as a tool for system programming.
Cyclone development was started as a joint project of AT&T Labs Research and Greg Morrisett's group at Cornell University in 2001. Version 1.0 was released on May 8, 2006.
Cyclone attempts to avoid some of the common pitfalls of C, while still maintaining its look and performance. To this end, Cyclone places the following limits on programs:
NULL checks are inserted to prevent segmentation faults
Pointer arithmetic is limited
Pointers must be initialized before use (this is enforced by definite assignment analysis)
Dangling pointers are prevented through region analysis and limits on free()
Only "safe" casts and unions are allowed
goto into scopes is disallowed
switch labels in different scopes are disallowed
Pointer-returning functions must execute return
setjmp and longjmp are not supported
To maintain the tool set that C programmers are used to, Cyclone provides the following extensions:
Never-NULL pointers do not require NULL checks
"Fat" pointers support pointer arithmetic with run-time bounds checking
Growable regions support a form of safe manual memory management
Garbage collection for heap-allocated values
Tagged unions support type-varying arguments
Injections help automate the use of tagged unions for programmers
Polymorphism replaces some uses of void *
varargs are implemented as fat pointers
Exceptions replace some uses of setjmp and longjmp
For a better high-level introduction to Cyclone, the reasoning behind Cyclone and the source of these lists, see this paper.
Cyclone looks, in general, much like C, but it should be viewed as a C-like language.
Cyclone implements three kinds of pointer:
(the normal type)
@ (the never-NULL pointer), and
? (the only type with pointer arithmetic allowed, "fat" pointers).
Cette page est générée automatiquement et peut contenir des informations qui ne sont pas correctes, complètes, à jour ou pertinentes par rapport à votre recherche. Il en va de même pour toutes les autres pages de ce site. Veillez à vérifier les informations auprès des sources officielles de l'EPFL.
Une erreur de segmentation (en anglais segmentation fault, en abrégé segfault) est un plantage d'une application qui a tenté d'accéder à un emplacement mémoire qui ne lui était pas alloué. Les applications, lorsqu'elles s'exécutent, ont besoin de mémoire vive, allouée par le système d'exploitation. Une fois allouée à l'application, aucune autre application ne peut avoir accès à cette zone ; cela garantit une sûreté de fonctionnement pour chaque application contre les erreurs des autres.
Rust est un langage de programmation compilé multi-paradigme conçu et développé par Mozilla Research depuis 2010. Il a été conçu pour être « un langage fiable, concurrent, pratique », supportant les styles de programmation purement fonctionnel, modèle d'acteur, procédural, ainsi qu'orienté objet sous certains aspects. En 2020, ses domaines de prédilection sont la programmation système, les applications en ligne de commande, les applications Web via WebAssembly, les services réseaux et les systèmes embarqués.
En programmation informatique, un pointeur est un objet qui contient l'adresse mémoire d'une donnée ou d'une fonction. C'est l'outil fondamental de l'adressage dit « indirect ». La notion de pointeur reflète l'utilisation différente que l'on peut faire d'un entier naturel, à savoir indiquer une adresse mémoire. Cette utilisation est très différente d'une utilisation arithmétique, d'où la création de registres de processeurs spécifiques (les registres d'adresse) et d'un type de donnée spécifique dans les langages de programmations.
Writing correct software is hard, yet in systems that have a high failure cost or are not easily upgraded like blockchains, bugs and security problems cannot be tolerated. Therefore, these systems are perfect use cases for formal verification, the task of ...
2021
,
Developers write low-level systems code in unsafe programming languages due to performance concerns. The lack of safety causes bugs and vulnerabilities that safe languages avoid. We argue that safety without run-time overhead is possible through type invar ...
Formal verification of real-world software systems remains challenging for a number of reasons, including lack of automation, friction in specifying properties, and limited support for the diverse programming paradigms used in industry. In this thesis we m ...