Chapter 16. Unsafe Code

Visual C# .NET (C#) allows you to step outside of the safe environment of managed code and write code that is considered "unsafe" by the Common Language Runtime (CLR). Running code that is considered unsafe by the CLR presents a certain set of restrictions in exchange for opening up possibilities like accessing memory-mapped data or implementing time-critical algorithms that use pointers directly. These restrictions are mainly based in the Code Access Security (CAS) system of the CLR and are in place to draw a distinct line between code the CLR knows to be playing by the rules (or "safe"), and code that needs to do a bit outside of the traditional sandbox of the CLR (and is thus "unsafe" code). In order to run code that is marked as unsafe by the CLR, you need the CAS SkipVerification privilege granted to the assembly that the unsafe code is implemented in. This tells the CLR to not bother verifying the code and to allow it to run, whereas normally unverified code would not run. This is a highly privileged operation and is not to be done lightly, as you increase the permissions your application will require in order to operate correctly on a user's system. If you use unsafe types in a method signature, you also make the code non-CLS-compliant. This means that interoperability with other .NET based languages, like VB.NET or Managed C++, for this assembly is compromised.

Even though unsafe code allows you to easily write potentially unstable code, it does have several safeguards. Only value types or pointers to value types inside of reference types can be used with unsafe code; reference types cannot. This allows pointer types to be created solely on the stack, so you do not have to use the new and delete operations to allocate and release memory to which the variable points. You only have to wait for the method that declared the pointer type to return, forcing the pointer to go out of scope and clearing any stack space devoted to this method. You can get into a bit of trouble if you are doing exotic things with unsafe code (such as pointing to a value type inside of a reference type) since this behavior allows access to heap-based memory and opens up the possibility for pointer pitfalls such as those seen in C++.