{"id":4127,"date":"2026-05-21T16:12:26","date_gmt":"2026-05-21T16:12:26","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/05\/21\/improving-c-memory-safety\/"},"modified":"2026-05-21T16:12:26","modified_gmt":"2026-05-21T16:12:26","slug":"improving-c-memory-safety","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/05\/21\/improving-c-memory-safety\/","title":{"rendered":"Improving C# Memory Safety"},"content":{"rendered":"

We\u2019re in the process of significantly improving memory safety in C#<\/a>. The unsafe<\/code> keyword is being redesigned to inform callers that they have obligations that must be discharged to maintain safety, documented via a new safety comment style. The keyword will expand from marking pointers to any code that interacts with memory in ways the compiler cannot validate as safe. The compiler will enforce that the unsafe<\/code> keyword is used to encapsulate unsafe operations. The result is that safety contracts and assumptions become visible and reviewable instead of implied by convention.<\/p>\n

We plan to release the new model and syntax (nominally a C# 16 feature) as a preview in .NET 11 and as a production release in .NET 12. It will initially be opt-in and may become the default in a later release. We will update templates to enable the new model just like we have done with nullable reference types. The early compiler implementation has landed in main<\/a> and is taking shape.<\/p>\n

C# 1.0 introduced the unsafe<\/code> keyword as the way to establish an unsafe context on types, methods, and interior method blocks, letting developers choose the most convenient scope. An unsafe context grants access to pointer features. A method marked unsafe<\/code> can use those features in its signature and implementation while unmarked methods cannot. We also exposed a set of unsafe types like System.Runtime.CompilerServices.Unsafe<\/code><\/a> and System.Runtime.InteropServices.Marshal<\/code><\/a> that required careful usage as a convention.<\/p>\n

The unsafe<\/code> keyword has since been reused and remixed in Rust and Swift, where those language teams gave it stricter, propagation-oriented semantics. C# 16 follows the same path, applies unsafe<\/code> uniformly (including on Unsafe<\/code> and Marshal<\/code> members) in the .NET runtime libraries, and most closely resembles the Rust implementation. The result: unsafe<\/code> stops marking a kind of syntax and starts marking a kind of contract; one the compiler can\u2019t verify, that a skilled developer has to read and uphold.<\/p>\n

C# already blocks unsafe code by default. Most developers won\u2019t notice any change when they enable the new model because they don\u2019t enable or use unsafe APIs. The default block will cover a much larger surface area when the C# 16 safety model is enabled. The new model establishes strong guard rails that are visible, reviewable, and enforced by the compiler. It is also an important tool to enforce engineering and supply chain standards. Memory safety has been a rising priority across industry and government<\/a> for several years, and AI-assisted code generation adds a new dimension as software production scales faster than human review.<\/p>\n

Safety<\/h2>\n

An earlier post discusses the structural safety mechanisms in .NET:<\/p>\n

\n

safety is enforced by a combination of the language and the runtime \u2026 Variables either reference live objects, are null, or are out of scope. Memory is auto-initialized by default such that new objects do not use uninitialized memory. Bounds checking ensures that accessing an element with an invalid index will not allow reading undefined memory \u2014 often caused by off-by-one errors \u2014 but instead will result in a IndexOutOfRangeException<\/code>.<\/p>\n<\/blockquote>\n

Source: What is .NET, and why should you choose it?<\/a><\/p>\n

C# comes with strong safety enforcement for regular safe code. The new model enables developers and agents to accurately mark safety boundaries in unsafe code. There are two reasons to write unsafe code: interoperating with native code, and in some cases for performance. Go, Rust, and Swift also include an unsafe dialect for these cases. The language typically cannot help you write unsafe code; its role is to make clear where unsafe code is used and how it transitions back to safe code.<\/p>\n

Programming safety may be easier to understand if we consider another domain. Road designers improve safety by painting solid yellow or white lines that prohibit crossing into oncoming traffic. Drivers understand and abide by this convention. High-speed highways use barriers to provide safety via structural separation that continues to function in the absence of sober compliance. The highway example shows us that higher speeds come with higher stakes.<\/p>\n

Programming has its own kind of accidents, with memory. Every application has potential access to gigabytes of virtual memory. Writing to or reading from arbitrary memory results in arbitrary behavior (Undefined Behavior<\/strong>, or UB<\/strong>, is the industry term) and is the cause of most security bugs<\/a>. Accessing arbitrary memory isn\u2019t possible in safe code, but is an ever-present possibility in unsafe code.<\/p>\n

The model in a nutshell<\/h2>\n

.NET programs are expected to uphold one core invariant: every memory access targets live memory<\/strong>: memory that is allocated, initialized, and available at the time of access. Safe code upholds this by construction: compiler rules and runtime checks combine to make a stray access impossible. Unsafe code<\/strong> is any operation that can violate the invariant, typically by reading or writing memory that isn\u2019t live, or by leaving memory in a state where a later access will fail.<\/p>\n

Unsafe code can read or write arbitrary memory accessed via interop, by NativeMemory<\/code>, or hand-managed by the developer. The invariant must hold all the same. The compiler can\u2019t detect UB there, so the burden of validation shifts to the developer.<\/p>\n

The solution to this risk is a layered set of mechanics that intentionally and transparently push unsafety through the call graph, each layer enabling the next:<\/p>\n

    \n
  1. Inner unsafe { }<\/code> block<\/strong>: every unsafe operation (calling an unsafe<\/code> member, dereferencing a pointer, and other unsafe<\/code> actions) must appear inside an inner unsafe { }<\/code> block. This is the base mechanic. Unsafe operations are syntactically marked, scoped, and reviewable.<\/li>\n
  2. Propagation<\/strong>: adding unsafe<\/code> to the enclosing method\u2019s signature republishes the inner block\u2019s obligations to its own callers, unless discharged. This carves the call graph into safe methods, unsafe<\/code> methods, and the boundary methods between them. Developers can chain propagation through any number of intermediates before someone decides to stop.<\/li>\n
  3. Safety documentation<\/strong>: every unsafe<\/code> member should carry a \/\/\/ <safety><\/code> block: the formal contract between callee and caller. Authoring it is a strongly encouraged best practice, and analyzers can flag its absence.<\/li>\n
  4. Suppression at the boundary<\/strong>: a method that contains an inner unsafe<\/code> block but does not<\/em> mark its own signature unsafe<\/code> is the boundary between unsafe and safe code. It discharges the callee\u2019s documented obligations, through runtime guards on inputs, static reasoning, or documented invariants from upstream APIs (e.g., malloc<\/code> guaranteeing the returned pointer is valid for at least size<\/code> bytes). Correct discharge is what makes safe callers actually safe.<\/li>\n<\/ol>\n

    You have to step through each layer to get the value. Do half the work and you get much less than half the value. Step through each layer correctly and you have a connected line of reasoning through a call graph that others can review and potentially improve.<\/p>\n

    Writing unsafe code is a special skill that requires a strong understanding of this invariant and of many pitfalls. The new model makes unsafe code easier to reason about and review, not easier to write \u2014 it forces a formal, visible structure. The keywords and compiler enforcement aren\u2019t the safety; they\u2019re the scaffolding that gets developers to articulate and honor it.<\/p>\n

    C# 1.0 grouped a category of \u201cpointer features\u201d under unsafe<\/code>: declaring and dereferencing pointer types, taking the address of variables, stackalloc<\/code> to a pointer, sizeof<\/code> on arbitrary types, and other capabilities added over the years, including the suppression of certain compiler errors. The new model is more selective.<\/p>\n

    Changes relative to C# 1.0 rules include:<\/p>\n