Unsafe Code in C#: Low-Level Memory Access, Pointers, Performance Optimization and Risks

Unsafe code in C# is a feature that allows developers to perform low-level memory manipulation using pointers, similar to C and C++. It bypasses many of the safety guarantees provided by the .NET runtime and gives direct access to memory addresses.

Normally, C# is a fully managed language where memory safety is handled by the CLR and Garbage Collector. Unsafe code breaks part of this abstraction to allow higher performance and more control over memory layout.

Unsafe code is used in:

• High-performance systems
• Game engines
• Image/audio processing
• Interop with native libraries
• Low-latency financial systems
• Serialization/deserialization engines

Why Do We Use Unsafe Code?

Unsafe code is used when managed abstractions are not fast enough or when direct memory control is required.

It allows developers to avoid overhead caused by:

• Bounds checking
• GC-managed allocations
• Object wrapping overhead
• Memory copying in some scenarios

This makes unsafe code useful in performance-critical sections of applications.

When Should You Use Unsafe Code?

Unsafe code should only be used when:

• Performance is critical and measured
• You need interoperability with native APIs
• You are working with raw binary data
• You are optimizing hot paths in algorithms
• Safe alternatives like Span<T> are insufficient

In most modern .NET applications, unsafe code is rarely required because Span<T>, Memory<T>, and modern APIs already cover many scenarios.

How Unsafe Code Works in C#

To use unsafe code, you must explicitly enable it using the unsafe keyword.

You also need to enable unsafe compilation in project settings.

Basic Unsafe Context

unsafe
{
  int value = 10;
  int* pointer = &value;
  Console.WriteLine(*pointer);
}

Pointers in C#

Pointers store memory addresses instead of values. They allow direct access to memory locations.

Pointer operations include:

• Address-of operator (&)
• Dereference operator (*)
• Pointer arithmetic

Pointer Example

unsafe
{
  int number = 42;
  int* ptr = &number;

  Console.WriteLine(*ptr);
}

Pointer Arithmetic

Pointers can be incremented or decremented to traverse memory.

unsafe
{
  int[] numbers = { 1, 2, 3 };

  fixed (int* ptr = numbers)
  {
    Console.WriteLine((ptr + 0));
    Console.WriteLine((ptr + 1));
  }
}

Fixed Keyword

The fixed keyword prevents the Garbage Collector from moving objects in memory during execution of unsafe operations.

This is required because GC compacts memory, which would otherwise invalidate pointers.

unsafe
{
  int[] array = { 10, 20, 30 };

  fixed (int* ptr = array)
  {
    Console.WriteLine(ptr[0]);
  }
}

stackalloc

stackalloc allocates memory on the stack instead of the heap. This avoids GC pressure and improves performance.

unsafe
{
  int* buffer = stackalloc int[5];

  for (int i = 0; i < 5; i++)
    buffer[i] = i * 10;
}

Unsafe vs Safe Code

Use Cases of Unsafe Code

• Image processing libraries
• High-performance serialization
• Game engines (physics, rendering)
• Interop with C/C++ libraries
• Low-level networking stacks

Advantages of Unsafe Code

• Maximum performance control
• Direct memory access
• Reduced overhead in hot paths
• Ability to integrate with native code
• Fine-grained memory optimization

Disadvantages of Unsafe Code

• Risk of memory corruption
• Harder debugging
• Security vulnerabilities
• GC safety restrictions
• Reduced portability and maintainability

Common Mistakes

• Using unsafe code without profiling
• Forgetting fixed when using pointers to managed memory
• Buffer overflows due to pointer arithmetic
• Overusing unsafe code instead of Span<T>
• Ignoring memory ownership rules

Best Practices

• Use unsafe code only in performance-critical sections
• Prefer Span<T> and Memory<T> when possible
• Always minimize unsafe scope
• Avoid exposing unsafe APIs publicly
• Profile before optimizing with pointers

Alternatives to Unsafe Code

Span<T>

Provides safe low-level memory access without GC pressure.

Memory<T>

Supports async-safe memory handling.

ArrayPool<T>

Reduces allocations without unsafe operations.

Conclusion

Unsafe code in C# provides powerful low-level memory control, enabling high-performance optimizations and interoperability with native systems. However, it comes with significant risks and should be used carefully and sparingly.

Modern .NET provides safer alternatives like Span<T> that eliminate the need for unsafe code in most scenarios, making it important to justify its use with real performance requirements.