Skip to content

Clarify properties of memory safety in .NET programs #375

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jkotas merged 7 commits into from
Oct 7, 2026
Merged

Clarify properties of memory safety in .NET programs #375

Changes from 3 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
3a8a39c
Clarify properties of memory safety in .NET programs
agocke Sep 15, 2026
00faad4
Update caller-unsafe.md
agocke Sep 18, 2026
776fad6
Define requirements for managed references in unsafe code
agocke Sep 18, 2026
9270c8d
Update managed references requirements in caller-unsafe.md
agocke Sep 18, 2026
0a9bd6c
Update managed references requirements for safety
agocke Sep 19, 2026
75d4d80
Clarify managed references requirements in documentation
agocke Sep 19, 2026
3eadb92
Apply suggestion from @jkotas
agocke Oct 7, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 10 additions & 1 deletion accepted/2025/memory-safety/caller-unsafe.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -114,7 +114,7 @@ public sealed class RequiresUnsafeAttribute : System.Attribute

### Global invariants

Two properties which should always hold in .NET programs are:
Properties which should always hold in .NET programs are:

* Memory safety
* No access to uninitialized memory
Expand Down Expand Up @@ -184,6 +184,15 @@ The last notable area of impact is source generation. Most users will only see c

One concession we could make to source generation would be to allow more fine-grained enabling and disabling of the warning scope. This proposal does **not** recommend such configuration switches. The `unsafe` feature is specifically designed to catch dangerous situations and source generation does not eliminate that risk. Therefore our recommendation would be to **avoid enabling the feature** until all source generators are updated to produce compatible code.

### Requirements

To uphold the global safety invariants, user code must uphold certain requirements.

In particular, managed references have the following requirements:

- Managed references must be aligned in safe code. Managed refereces are often pinned as unmanaged pointers and passed to native code using C/C++ conventions. C/C++ requires that all pointers are properly aligned, the behavior is undefined otherwise and it can lead to memory safety violations.

@jkotas jkotas Sep 19, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is almost exact duplicate of what's written a few paragraphs below. Did you mean to consolidate it?

@agocke agocke Sep 19, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, my mistake

- Managed references may be null, but if they are non-null then they must point to valid memory, _even in unsafe code_. For these purposes, one element past the end of an array is considered valid memory.

@jkotas jkotas Sep 19, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not capturing all nuances.

For example, we also allow "the address computed by adding the address of a field and the sizeof of the type of that field" that is not necessarily a valid memory. On the other hand, we prohibit valid memory that was not explicitly allocated on managed or native heap (for example, it is invalid for a byref to point into the GC control data structures). It may be best to just link to https://github.com/dotnet/runtime/blob/main/docs/design/specs/Ecma-335-Augments.md#ii1442 .

@agocke agocke Sep 19, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, fair enough -- linking seems easy enough. I suppose that the only things that we need to state here are things that are only allowed in unsafe code, not things that are disallowed in both safe and unsafe code?


### Examples and APIs

**ArrayPool.Rent**
Expand Down
Loading