Skip to content
Open
Changes from all commits
Commits
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
9 changes: 8 additions & 1 deletion docs/design/specs/Ecma-335-Augments.md
Original file line number Diff line number Diff line change
Expand Up @@ -1030,6 +1030,13 @@ Changes to signatures:
- Managed pointers which point at the address just past the end of an object, or the address where an element just past the end of an array would be stored, are permitted but not dereferenceable.
- Null managed pointers are permitted to be dereferenced resulting in a `NullReferenceException`.

### III.1.7.7
Add a new paragraph "III.1.7.7 Managed pointers exposing parameters outside of the method scope" under section "III.1.7 Restrictions on CIL code sequences"
Byrefs derived from method parameters can escape from a function only in the following ways:
Copy link
Member

Choose a reason for hiding this comment

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

What does "derived" mean exactly? The existing uses of "derived" in the ECMA spec are about inheritance.

Copy link
Member Author

Choose a reason for hiding this comment

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

When we take a byref from a parameter directly or from any of its fields or array elements.

Byrefs obtained from parameters directly or indirectly (byrefs to their fields or array elements)

is it better?

Copy link
Member

@jkotas jkotas Jan 2, 2026

Choose a reason for hiding this comment

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

array elements

Marshal.UnsafeAddrOfPinnedArrayElement does exactly that. I think this needs to be more limited.

- By explicit return of a byref or byref-like type
- By writing through a byref to a byref-like type or byref-like type containing multiple levels of byref fields. For example: `Span<T> p` parameter cannot expose anything, while `ref Span<T> p` can.
The behavior is undefined if any other form of escape is attempted.

## <a name="byreflike-generics"></a> ByRefLike types in generics

ByRefLike types, defined in C# with the `ref struct` syntax, represent types that cannot escape to the managed heap and must remain on the stack. It is possible for these types to be used as generic parameters, but in order to improve utility certain affordances are required.
Expand Down Expand Up @@ -1194,4 +1201,4 @@ In section II.23.1.15, the following row is added to the table:

## Implict argument coercion rules

Implicit argument coercion as defined in section III.1.6 does not match with existing practice in CLR runtimes. Notably, implicit argument coercion of an `int32` on the IL evaluation stack to a `native unsigned int` is a sign extending operation, not a zero-extending operation.
Implicit argument coercion as defined in section III.1.6 does not match with existing practice in CLR runtimes. Notably, implicit argument coercion of an `int32` on the IL evaluation stack to a `native unsigned int` is a sign extending operation, not a zero-extending operation.