ECMA-334 C# Language Specification

25.1: Unsafe contexts

The unsafe features of C# are available only in unsafe contexts. An unsafe context is introduced by including an unsafe modifier in the declaration of a type or member, or by employing an unsafe-statement:

The associated grammar extensions are shown below. For brevity, ellipses (...) are used to represent productions that appear in preceding chapters.

class-modifier
...
unsafe
struct-modifier
...
unsafe
interface-modifier
...
unsafe
delegate-modifier
...
unsafe
field-modifier
...
unsafe
method-modifier
...
unsafe
property-modifier
...
unsafe
event-modifier
...
unsafe
indexer-modifier
...
unsafe
operator-modifier
...
unsafe
constructor-modifier
...
unsafe
destructor-declaration
attributesoptextern optunsafe opt ~ identifier ( ) destructor-body
attributesoptunsafe optextern opt ~ identifier ( ) destructor-body
static-constructor-declaration
attributesoptextern optunsafe optstatic identifier ( ) static-constructor-body
attributesoptunsafe optextern optstatic identifier ( ) static-constructor-body
embedded-statement
...
unsafe-statement
unsafe-statement
unsafe block

[Example: In the example
public unsafe struct Node  
{  
   public int Value;  
   public Node* Left;  
   public Node* Right;  
}  
the unsafe modifier specified in the struct declaration causes the entire textual extent of the struct declaration to become an unsafe context. Thus, it is possible to declare the Left and Right fields to be of a pointer type. The example above could also be written
public struct Node  
{  
   public int Value;  
   public unsafe Node* Left;  
   public unsafe Node* Right;  
}  

Here, the unsafe modifiers in the field declarations cause those declarations to be considered unsafe contexts. end example]

Other than establishing an unsafe context, thus permitting the use of pointer types, the unsafe modifier has no effect on a type or a member. [Example: In the example
public class A  
{  
   public unsafe virtual void F() {  
      char* p;  
      ...  
   }  
}  
public class B: A  
{  
   public override void F() {  
      base.F();  
      ...  
   }  
}  
the unsafe modifier on the F method in A simply causes the textual extent of F to become an unsafe context in which the unsafe features of the language can be used. In the override of F in B, there is no need to re-specify the unsafe modifier-unless, of course, the F method in B itself needs access to unsafe features.

The situation is slightly different when a pointer type is part of the method's signature
public unsafe class A  
{  
   public virtual void F(char* p) {...}  
}  
public class B: A  
{  
   public unsafe override void F(char* p) {...}  
}  

Here, because F's signature includes a pointer type, it can only be written in an unsafe context. However, the unsafe context can be introduced by either making the entire class unsafe, as is the case in A, or by including an unsafe modifier in the method declaration, as is the case in B. end example]