Unsafe evolution

[333fred]

Discussion topic for unsafe evolution.

Champion issue: #9704

[ufcpp]

What about the /unsafe (AllowUnsafeBlocks) compiler command-line option?
If Array.Rent becomes caller-unsafe and requires the /unsafe option, nearly all the projects I maintain would end up requiring /unsafe. It would become an option that should always be set to true, similar to nullable enable.

[TahirAhmadov]

PS. Maybe instead of _disposed checking in my idea of cloning Span<T> surface area to a "rental" struct, the actual field can just be made null; then there is no added cost - the standard null check catches them "using it after free" (with a not so user-friendly NRE, but still). The incompatibility with T[] and even Span<T> is still a huge problem, though.

[TahirAhmadov]

PPS. Damn it, that doesn't work if the SpanRental<T> type is a struct; it works if it's a class, but then we're right back to allocating 🤣 (to be fair, it's a tiny instance holding a reference to a rented array)
OK I give up, you guys figure it out 🤣

[colejohnson66]

Is it even possible to solve the ArrayPool<T> UAF problem in C# without going "full lifetimes" like Rust? Because, if Return is annotated as "moving" the array, it would stop me from immediately doing a UAF. But if I stuffed that array somewhere, then returned it, how do you annotate that the other objref is now invalid?

[333fred]

Is it even possible to solve the ArrayPool UAF problem in C# without going "full lifetimes" like Rust?

No, and it is not a goal of this proposal to do so.

[jilles-sg]

The above ref struct ArrayRental<T> seems pretty close to a watertight use-after-free prevention for some ArrayPool<T> use cases. It will only work if merely a span is required (not an array or Memory<T> for a legacy API or async). What is additionally needed:

• An [UnscopedRef] attribute on the Span getter which ties the lifetimes so the returned span cannot be used after the ArrayRental wrapper is gone. A readonly modifier may be useful too to prevent copies because using defines readonly variables.
• An analyzer that ensures ArrayRental can only be used as using ArrayRental<T> rental = new ArrayRental<T>(...);, using (ArrayRental<T> rental = new ArrayRental<T>(...)) { ... } or calling the Span getter, to prevent using the span after Dispose, copying the wrapper and using it after the original has been disposed, etc. Alternatively, making the wrapper a move-only struct could work.

A downside is the try/finally wrapper which is really unnecessary overhead.

[huoyaoyuan]

Besides the one AllowUnsafeBlocks option, we should provide a clear guidance about the levels about safety.

There are various practices that disallow unsafe syntax, instead using Marshal that provides even less type-safety.

[333fred]

It's about the wrong external rules to disable unsafe and prefer Marshal.

The point of this feature is to alert people that Marshal is unsafe.

[huoyaoyuan]

The point of this feature is to alert people that Marshal is unsafe.

I want it to clarify that Marshal is more unsafe, not equivalently. Extending the scope of unsafe can introduce a risk for people to be desensitized from the most dangerous ones.

[CyrusNajmabadi]

Can you expand on that @huoyaoyuan ? Thanks!

[tannergooding]

The consideration is largely the concept that T* is more safe than void* or nint/nuint because it doesn't lose the context that it is T and that it is one indirection.

Many people opted to use Marshal.X() because it didn't require unsafe { } not understanding that it was "more unsafe" (error prone) due to losing much of the contextual information. There's all kinds of subtle edge cases and considerations that come into play here.

Now with that being said, I don't think it's the responsibility of the language to decide to expose such a semantic to the user. It's the responsibility of the libraries team to decide which APIs we want to be unsafe callers only and whether we want to provide any analyzers pointing users to modern alternatives or to provide overloads that do take pointers instead.

That is, the language just needs to provide the unsafe callers only feature and then the libraries team will decide when and where to apply it. Various Marshal APIs are one such case and we've had discussions on analyzers or other things in the past to help get users onto "better" alternatives to cover the consideration that there are other usability issues (beyond being unsafe) for the Marshal APIs

[huoyaoyuan]

Generally I'd like to see more codified contract of "level of safety" in https://learn.microsoft.com/en-us/dotnet/standard/unsafe-code/best-practices .

[richlander]

These documents should be captured in the conversation:

• https://github.com/dotnet/designs/blob/main/accepted/2025/memory-safety/memory-safety.md
• https://learn.microsoft.com/en-us/dotnet/standard/unsafe-code/best-practices

The second doc gets a bit at "levels of safety".

[TahirAhmadov]

These were very illuminating. I don't do almost any unsafe code, and learned a lot about various edge cases - not super useful to me today, but very educational. Great documents!

[richlander]

The analogous Rust docs are very good: https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html

[IS4Code]

First I need to say that I agree with the overall effort to indicate clearly, and consistently, what methods have the "standard safety guarantees" and which do not, and to give users the ability to track (and restrict) sources of unsafety in their programs. This could be a great feature that helps users understand how careful they need to be in using certain features, beyond just the scope of pointers.

However, I think the solution to annotate "everything" in .NET with [RequiresUnsafe] falls short of one, crucial, thing:

• When a user is given a choice between adding <AllowUnsafeBlocks> due to pointers, and virtually any other solution that does not require it, the user most likely picks the latter.

This is an issue because it means that actually unsafe code is oftentimes safer than non-unsafe code. Pointers are type-checked, IntPtr and Marshal are not. And even with unsafe, C# still tries hard to warn you when doing something weird (like object*) is probably wrong, to the point that I could reasonably say that C# is even better at pointer manipulation than C!

So my first idea: ditch <AllowUnsafeBlocks>. It has done an abysmal job at protecting you from unsafe code and it will never improve. It "taints" the whole project for absolutely no reason ‒ you can still write unverifiable code even without unsafe. Any solution that relies on pretty much everything in the ecosystem to progress to a "new unsafe" will always be leaky ‒ any new changes to .NET will not transfer to .NET Standard and .NET Framework anyway, libraries will take long to adapt, and some may decide not to. Relying on this will only lead to a fake sense of safety that breaks the first time someone does something unusual.

Embrace unsafe ‒ if someone absolutely needs to use it, let them! Either don't require the compiler switch at all, or have something like #unsafe enable (source of inspiration obvious) that works on a file level. This way, people should not feel "bad" for using unsafe when the alternatives are just as horrendous, because then at least such a thing is clearly marked.

Now the practical part ‒ I like the introduction of [RequiresUnsafe], but I think that should be enough. It is not worth redefining a keyword to suddenly mean something else in certain contexts, especially considering this is a keyword that is really crucial not to misunderstand. Doing any such breaking changes, even if opt-in (as I have gathered), means the phrase "there is an unsafe method" suddenly gets a new meaning that is ambiguous depending on the C# version, compiler switches, and so on. Every old documentation would become misleading. Unlike in Rust, we should cherish that, right now, unsafe in C# really has had a single connotation of "it's on me". I just don't find any reason for that other than it being shorter than writing [RequiresUnsafe]. Has that become the metric for breaking changes now?

If unsafe gets a new meaning, not only that means rewriting existing code to be sure it retains the old meaning is error-prone, confusing and potentially introducing hidden API breaks, but it also means some constructs will be not only inconvenient, but straight up impossible to write without subsequent changes or new features just to mimic the old one's behaviour:

// Can't put `unsafe` just around the base interface
interface IThing : IEnumerable<void*[]>; // So maybe referencing a pointer type would not require `unsafe` anymore?

class Base
{
    // Maybe `unsafe` not required anymore even with pointer parameters?
    public unsafe Base(int* x) {}
}

class Derived : Base
{
    // Can't put `unsafe` just around the base call... but what if the base constructor is `[RequiresUnsafe]` but the derived one should not be?
    public Derived(IntPtr ptr) : base(Convert(ptr))
    {
    
    }
    
    static unsafe int* Convert(IntPtr ptr) => (int*)ptr;
}

It is my understanding of the proposed new meaning of the unsafe keyword (even though I did not perceive any particular harmony in people's intuition around it) that it basically means that any enclosed members are automatically [RequiresUnsafe], so unless there is a way to smuggle unsafe after the :, expressing such a thing would be quite difficult.

This kind of removing a feature just to replace it with a similar-looking one only to have to come up with ways of filling the holes that action have caused reminds me of a certain children's tale, where the family bought a Christmas tree, but they noticed it was a bit flat on one side, as if missing a branch. So they drilled a hole inside the trunk there, cut a branch from another side, and inserted it in the hole. But then they noticed it was flat on the side where they cut the branch, so they sawed off another branch and shoved it into a newly drilled hole there. When they were finally happy, someone accidentally shook the tree and all the branches fell off.