Memory-safe dialect of the C programming language
The Cyclone programming language was intended to be a safe dialect of the C language. It avoids buffer overflows and other vulnerabilities that are possible in C programs by design, without losing the power and convenience of C as a tool for system programming. It is no longer supported by its original developers, with the reference tooling not supporting 64-bit platforms. The Rust language is mentioned by the original developers for having integrated many of the same ideas Cyclone had.
Cyclone development was started as a joint project of Trevor Jim from AT&amp;T Labs Research and Greg Morrisett's group at Cornell University in 2001. Version 1.0 was released on May 8, 2006.
Language features.
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:
To maintain the tool set that C programmers are used to, Cyclone provides the following extensions:
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.
Pointer types.
Cyclone implements three kinds of pointer:
The purpose of introducing these new pointer types is to avoid common problems when using pointers. Take for instance a function, called codice_17 that takes a pointer to an int:
 int foo(int *);
Although the person who wrote the function codice_17 could have inserted codice_1 checks, let us assume that for performance reasons they did not. Calling codice_20 will result in undefined behavior (typically, although not necessarily, a SIGSEGV signal being sent to the application). To avoid such problems, Cyclone introduces the codice_14 pointer type, which can never be codice_1. Thus, the "safe" version of codice_17 would be:
 int foo(int @);
This tells the Cyclone compiler that the argument to codice_17 should never be codice_1, avoiding the aforementioned undefined behavior. The simple change of codice_13 to codice_14 saves the programmer from having to write codice_1 checks and the operating system from having to trap codice_1 pointer dereferences. This extra limit, however, can be a rather large stumbling block for most C programmers, who are used to being able to manipulate their pointers directly with arithmetic. Although this is desirable, it can lead to buffer overflows and other "off-by-one"-style mistakes. To avoid this, the codice_16 pointer type is delimited by a known bound, the size of the array. Although this adds overhead due to the extra information stored about the pointer, it improves safety and security. Take for instance a simple (and naïve) codice_31 function, written in C:
 int strlen(const char *s)
 int i = 0;
 if (s == NULL)
 return 0;
 while (s[i] != '\0') {
 i++;
 return i;
This function assumes that the string being passed in is terminated by codice_32. However, what would happen if were passed to this string? This is perfectly legal in C, yet would cause codice_31 to iterate through memory not necessarily associated with the string codice_34. There are functions, such as codice_35 which can be used to avoid such problems, but these functions are not standard with every implementation of ANSI C. The Cyclone version of codice_31 is not so different from the C version:
 int strlen(const char ? s)
 int i, n = s.size;
 if (s == NULL)
 return 0;
 for (i = 0; i ; n; i++, s++)
 if (*s == '\0')
 return i;
 return n;
Here, codice_31 bounds itself by the length of the array passed to it, thus not going over the actual length. Each of the kinds of pointer type can be safely cast to each of the others, and arrays and strings are automatically cast to codice_16 by the compiler. (Casting from codice_16 to codice_13 invokes a bounds check, and casting from codice_16 to codice_14 invokes both a codice_1 check and a bounds check. Casting from codice_13 to codice_16 results in no checks whatsoever; the resulting codice_16 pointer has a size of 1.)
Dangling pointers and region analysis.
Consider the following code, in C:
 char *itoa(int i)
 char buf[20];
 sprintf(buf,"%d",i);
 return buf;
The function codice_47 allocates an array of chars codice_48 on the stack and returns a pointer to the start of codice_48. However, the memory used on the stack for codice_48 is deallocated when the function returns, so the returned value cannot be used safely outside of the function. While GNU Compiler Collection and other compilers will warn about such code, the following will typically compile without warnings:
 char *itoa(int i)
 char buf[20], *z;
 sprintf(buf,"%d",i);
 z = buf;
 return z;
GNU Compiler Collection can produce warnings for such code as a side-effect of option or , but there are no guarantees that all such errors will be detected.
Cyclone does regional analysis of each segment of code, preventing dangling pointers, such as the one returned from this version of codice_47. All of the local variables in a given scope are considered to be part of the same region, separate from the heap or any other local region. Thus, when analyzing codice_47, the Cyclone compiler would see that codice_53 is a pointer into the local stack, and would report an error.
References.
 ;templatestyles src="Reflist/styles.css" / ;
External links.
Presentations: