Editing Cyclone (programming language) (section)

===Pointer types===
Cyclone implements three kinds of [[pointer (computer science)|pointer]]:
* <code>*</code> (the normal type)
* <code>@</code> (the never-<code>NULL</code> pointer), and
* <code>?</code> (the only type with [[pointer arithmetic]] allowed, [[fat pointer|"fat" pointer]]s).
The purpose of introducing these new pointer types is to avoid common problems when using pointers. Take for instance a function, called <code>foo</code> that takes a pointer to an int:
<syntaxhighlight lang="C">
 int foo(int *);
</syntaxhighlight>
Although the person who wrote the function <code>foo</code> could have inserted <code>NULL</code> checks, let us assume that for performance reasons they did not. Calling <code>foo(NULL);</code> will result in [[undefined behavior]] (typically, although not necessarily, a [[SIGSEGV]] [[Unix signal|signal]] being sent to the application). To avoid such problems, Cyclone introduces the <code>@</code> pointer type, which can never be <code>NULL</code>. Thus, the "safe" version of <code>foo</code> would be:
<syntaxhighlight lang="C">
 int foo(int @);
</syntaxhighlight>
This tells the Cyclone compiler that the argument to <code>foo</code> should never be <code>NULL</code>, avoiding the aforementioned undefined behavior. The simple change of <code>*</code> to <code>@</code> saves the programmer from having to write <code>NULL</code> checks and the operating system from having to trap <code>NULL</code> 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 overflow]]s and other "off-by-one"-style mistakes. To avoid this, the <code>?</code> 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) <code>strlen</code> function, written in C:
<syntaxhighlight lang="C">
 int strlen(const char *s)
 {
     int i = 0;
     if (s == NULL)
        return 0;
     while (s[i] != '\0') {
        i++;
     }
     return i;
 }
</syntaxhighlight>
This function assumes that the string being passed in is terminated by <code>'\0'</code>. However, what would happen if {{code|style=white-space:nowrap|2=c|1=char buf[6] = {'h','e','l','l','o','!'};}} were passed to this string? This is perfectly legal in C, yet would cause <code>strlen</code> to iterate through memory not necessarily associated with the string <code>s</code>. There are functions, such as <code>strnlen</code> which can be used to avoid such problems, but these functions are not standard with every implementation of [[ANSI C]]. The Cyclone version of <code>strlen</code> is not so different from the C version:
<syntaxhighlight lang="C">
 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;
 }
</syntaxhighlight>
Here, <code>strlen</code> 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 <code>?</code> by the compiler. (Casting from <code>?</code> to <code>*</code> invokes a [[bounds checking|bounds check]], and casting from <code>?</code> to <code>@</code> invokes both a <code>NULL</code> check and a bounds check. Casting from <code>*</code> to <code>?</code> results in no checks whatsoever; the resulting <code>?</code> pointer has a size of 1.)