Improving C# Memory Safety

https://devblogs.microsoft.com/dotnet/improving-csharp-memory-safety/

by soheilpro • 2 months ago

166 45 2 months ago

devblogs.microsoft.com

pjmlp8• 2 months ago

Most likely a side effect related to Windows team finally giving some C# love, instead of COM and C++, given the comparisons between C# 16 with Rust and Swift in a few article sections.

moomin2• 2 months ago

The Windows team is talking to DevDiv again? Satan's putting on his ice skates right now.

pjmlp8• 2 months ago

One can only hope.

C++/WinRT is in maintenance, and you will notice the WinUI 3.0 does most of their demos, and gallery with C#.

superjan• 2 months ago

What you can do in C# today is convert any unsafe pointer to Span whenever you get your hands on it, and pass around slices. You can still drop down to ‘fixed’ when it turns out you need it for performance.

legulere2• 2 months ago

With fixed you do pinning on GC memory, which can have a negative performance effect. You can also do unchecked pointer arithmetics on references with the Unsafe class, which avoids that. A lot of the methods of Span use that internally.

sedatk• 2 months ago

I could say that the perf difference between spans and unsafe pointers in most cases is just zero, if not in favor of spans at times due to the optimized helper methods or just better code generation. Add the safety benefits to the mix, and it's a no brainer. So, unsafe pointers may not have an edge for performance anymore. They might have other uses cases of course: interop, etc.

SideburnsOfDoom• 2 months ago

The unsafe keyword is being redesigned

OK, I see a lot of C# code often and over a long time.

I see the "unsafe" keyword used approximately never.

I'm sure that this is useful for some cases. But not everyday things for most of us. If we did use it, it would be carefully isolated in a library for a specific purpose.

pjmlp8• 2 months ago

Many of us use it in scenarios where others would write a blog post about a rewrite in Rust, C++ or whatever.

CLR was designed to support languages like C++, yet many don't learn the knobs.

Weebs2• 2 months ago

Any lesser known knobs one should know? I'm considering a .NET backend for my compiler

tialaramex• 2 months ago

This moves C# to a more modern systematic understanding of what this keyword is for, but it'll remain very rare in C# the same way it's rare in Rust, and presumably in Swift.

The choice of keyword "unsafe" is partly psychological. Turns out if you called this exact same feature "trusted" or whatever the programmers don't have the appropriate feelings about it. They want to write trusted code, they don't want to write unsafe code, so making them write the keyword "unsafe" provides that psychological disincentive.

pixl97• 2 months ago

Initialize liveHandgrenade;

smt88• 2 months ago

C# is like Rust in the sense that a regular (web, desktop, etc.) developer probably won’t need unsafe, but it’s useful for lower-level work in libraries and CLI tools, especially where performance is important.

Quothling• 2 months ago

Around here C# is only really used at stagnant middle sized companies with horrible code bases. The sort where the company follow Uncle Bob religiously, while completely misunderstanding everything Uncle Bob ever said. Doesn't mean the language (and it's runtime) can't be good.

caspper692• 2 months ago

Yes, many people instinctively stay away from anything microsoft (except github, typescript and npm). But the stack is solid. I’m always reminded of Stack Overflow and how they built on asp.net and like 7 servers and it scaled very well for years.

Everyone has what they like and what they’re familiar with, and for better or worse, especially for startups it’s rarely .net. But I couldn’t imagine e.g. using js instead on the back end, but that’s just me.

legulere2• 2 months ago

The examples in Clean Code show that Uncle Bob himself misunderstood heuristics as strict rules that are to be taken to the extreme. There's nothing to not misunderstand.

zmj• 2 months ago

There are standard library APIs that let you do memory-unsafe things without the unsafe keyword (CollectionsMarshal, MemoryMarshal). They're useful, but the burden is on the caller to uphold the invariants. This proposal seems aimed at making that kind of contract more explicit and obvious.

Profan• 2 months ago

In a game development context, especially where C++ interop is involved and a lot of code lives across a boundary where memory is owned by C++ but you want to avoid/minimize marshaling overhead or just generally maximize performance, the unsafe keyword is quite handy, but outside of those you can indeed probably get around by approximately never using it.

There's a lot of power C# gives you if carefully curated, making a lot of cases where people previously might have seen C++ as the only option as suddenly quite viable.

... See also the somewhat arcane Unsafe.As etc APIs

WorldMaker2• 2 months ago

Yes, the article itself even points out that the C# default has always been to make the unsafe keyword a compile error by default and must be opted in at the project level to even use it. So most C# application code doesn't use unsafe.

The benefits here are mostly to specific types of libraries, often either deeply performance-focused libraries or complex native interop libraries (things that wrap C/C++/Rust/etc code as a .NET Library).

The article mostly also points out that like Span<T> many of the biggest benefits to application writers here are going to be making the runtime itself quietly better (faster and safer). The new compile errors will make Base Class Library code and runtime code more auditable for potential memory safety issues by bubbling up safety concerns higher into the code stack and making the boundaries between the unsafe and "safe" code much easier to find. It will provide additional incentive to narrow the number of things that need to be marked `unsafe` and provide extra incentive to the runtime to minimize `unsafe` dependencies. This includes adding additional weight furthering the push for rewrites from "performance" C++ code (under the hood of the runtime) to memory safe C# code with modern safety/performance tools like Span<T>, while also reducing some of the similar pressure to rewrite that C++ code as Rust for memory safety reasons rather than directly to C# (with less overhead of transitioning to/from "managed code" and "native code") by providing similar `unsafe` safety marker tools to what Rust has had since 2024.

(ETA: There may still be some possible breaking changes to today's application code when opting into the new safety checks though by adding possibly more uses of the unsafe keyword than were needed before as many APIs with unsafe in the name or documentation such as the Marshall.* family of functions will probably get new safety documentation. Most of those concerns are still in P/Invoke and native library interop spaces and would probably be refactored into libraries to re-isolate the unsafe code and have the application continue to not allow unsafe blocks, but that will be tech debt migrations that may show up when opting into the new behaviors.)

wvenable• 2 months ago

I see the "unsafe" keyword used approximately never.

The core libraries of .NET are written in C# and it's like a completely different language:

https://github.com/dotnet/runtime/blob/main/src/libraries/Sy...

One might not make use of it application code but these features a major part of the platform itself.

EFLKumo4• 2 months ago

Good language has a unique flavor, and better language allows for diverse tastes and usages

northlondoner2• 2 months ago

Compiler will enforce this. You won't be able to build without `unsafe` keyword. AFAIU.

caspper692• 2 months ago

They are aligning more closely with the Rust 2024 model for unsafety, which requires inner annotations at the point of unsafety in addition to notation of the function (unless it is the safe-unsafe boundary) plus it imposes a requirement for a SAFETY doc notation for describing the specific invariants the caller must enforce to uphold the safety guarantees. Not terribly onerous in my opinion. I maintain a few native library wrappers on nuget, so I will have to do some updates around IntPtr usage, but this doesn’t seem like it will be terribly painful in my case. Thankfully I don’t do much marshalling. Plus you get a nifty badge on nuget for making your library safe.

The blurb toward the end about Rent/return makes me a bit nervous though. They say they’re not going full borrow checker, but rent at least sounds an awful lot like borrow to me. Details were basically non-existent though.

I guess I wonder what the end game is here though. The more they make C# like Rust with a GC, the less incentive people have to use C# except maybe to support legacy work. I am still far more comfortable in C# than Rust, and I believe C# is superior for e.g. web, but over time this advantage could be lessened quite a bit as the Rust ecosystem continues to grow.

masklinn• 2 months ago

The blurb toward the end about Rent/return makes me a bit nervous though. They say they’re not going full borrow checker, but rent at least sounds an awful lot like borrow to me. Details were basically non-existent though.

Since they state outright that they're not going for a borrow checker, I would assume they're going for "second class references": the borrow checker is both powerful and complicated because references are first-class types: you can pass a reference as parameter, you can return a reference, and you can store a reference.

You can get a lot of the benefits (though also lose a fair amount of expressive power) if you drop the last two and only allow borrows downwards, and that is way easier to track.

Graydon Hoare's original conception of rust used second-class references (https://graydon2.dreamwidth.org/307291.html#:~:text=First-cl...). The Val language uses second-class references. Hylo (formerly Val) uses second-class references under the name of mutable value semantics (https://www.jot.fm/issues/issue_2022_02/article2.pdf).

Although the rent/return case doesn't even seem like a references concern, instead it's affine types which is orthogonal: after you `Return` an array to the pool, you want the array to become inaccessible to the caller (you could make the value linear, but as the text explains missing a `Return` is a safe leak it doesn't look like that's in scope). Rust mutable references are affine but you don't need references to do this...

ameliaquining• 2 months ago

C# already has second-class references; this is essentially what the ref keyword does. It's actually a bit more expressive than what Hoare suggests he'd have done (you can return ref structs and you can store them in other ref structs), but it doesn't have full-blown Rust-style lifetime annotations.

gertlabs• 2 months ago

C# is one of the best languages we evaluated for LLM problem solving. In fact, many strongly typed, lower level languages perform well in our testing (this isn't to say that the solutions are more maintainable, but the LLMs come up with better ideas when writing C# or Rust than Python). Google models especially, for whatever reason, outperform in C#, not Golang.

Data at https://gertlabs.com/rankings?provider=google

reactordev2• 2 months ago

This is why C# is superior to C++ for game development (not the graphics low level, but the game play higher level).

Being able to use Events, ECS, Reflection, Dynamic code is a god send. I have written game engines in C# and I still find myself defaulting to it anytime I think about Vulkan. I even published my own bindings for it. The best thing about .Net unfortunately is also one of its worst.

The deployment and packaging situation. It’s better than it’s been but it’s still a freaking mess. A mix of undocumented cli commands and wacky xml so that I can get an amalgamated build… or if I wanted to target another OS… or something of that nature. Even adding a project reference to a project, you have to go the long way round and use the cli commands. It’s better than having to install Visual Studio Ultimate but I wish they would put some love into their VSCode extension to give .Net some more powah.

Other than that, if you need Cish speed but need to support a GUI or something, C# is a good choice. If you’re happy with HTML UI, use that and forget C#. The UI cross platform situation is basically MIA.

scott01• 2 months ago

I respectfully disagree — a lot of conveniences that C# provides produce GC trash which will cause frame spikes. I remember having had to add a non-allocation string.contains alternative at one project. Lambdas and linq also have this problem, or if a string is passed through native-c# boundary. Language itself is really nice though :)

pjmlp8• 2 months ago

Google is mainly a user of Java, Kotlin, Python and C++.

Go might be have been created by three Google employees, two of which UNIX idols, but the language isn't that widely deployment outside anything to do with Kubernetes.

See how much Go related content shows at Google IO. If I am not mistaken, it got a single talk this year.

benol• 2 months ago

It's widely used in Cloud. Within Cloud you there is a policy to use it for all new products.

EFLKumo4• 2 months ago

Go is actually widely adopted in web backends and desktop apps. You might just miss some scenarios. And from my naive perspective, Go is a strong type alternative than TypeScript though it has a unique idiom syntax, but for most web devs this could be a reason to adopt Go, e.g. Wails instead of Electron in desktop.

Dwedit• 2 months ago

Are they finally marking all those functions that use IntPtrs as unsafe? (such as Marshal.Copy)

orphea• 2 months ago

Not really, because IntPtr is just a native-sized integer.

Marshal.Copy will certainly be marked unsafe, as will anything else that touches unmanaged memory.

WorldMaker2• 2 months ago

This change suggests that passing pointers is "generally safe", the unsafe boundaries are when they are de-referenced. It sounds like the Marshal methods are probably going to get a lot of surprising new safety warnings, but not all of them just because of the use of IntPtr. This change does open more opportunities to switch IntPtr to more explicit type-safe options like void* or byte* as the new compiler no longer needs unsafe {} blocks around just passing around pointers from one function to another.

effnorwood• 2 months ago

just use perl instead

northlondoner2• 2 months ago

Superb development. This would elevate C# into first class systems language, Linux Kernel level.

Improving C# Memory Safety

Related Stories