Simplify range validation in `Memory.Span` by xtqqczze · Pull Request #118585 · dotnet/runtime

xtqqczze · 2025-08-11T14:44:43Z

desiredStartIndex cannot be negative as high order bit of _index has been removed.
desiredLength cannot be negative as all public constructors validate _length is not negative.
lengthOfUnderlyingSpan cannot be negative as _object.Length as the length property of an array, string, or span cannot be negative.

dotnet-policy-service · 2025-08-11T14:45:35Z

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

EgorBo · 2025-08-11T15:07:18Z

-#else
- if ((uint)desiredStartIndex > (uint)lengthOfUnderlyingSpan || (uint)desiredLength > (uint)lengthOfUnderlyingSpan - (uint)desiredStartIndex)
+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


if this + overflows the check is passed, isn't ?

desiredLength should never be negative, this could do with an assert
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Line 330 in 8b10891
intdesiredLength=_length;

Yes - it's why the 32-bit target check is written the way it was below (which is a common overflow-avoiding pattern).
We can't "simplify" this, though - the 64 and 32 bit targets are different for a reason; they're taking advantage of different bit widths (or not able to) on different platforms.

This is the kind of thing where the logic is getting even more dense and hard to comprehend
I would much rather we do such transforms in the JIT when we know that a given invariant is held, so that the high level managed code can remain easy to understand.
Otherwise, this needs a significant number of comments and asserts covering those invariants and why the various overflow considerations are "safe" before it could be accepted.

The check here is only to prevent undefined behaviour if the struct is torn, if it wasn't for this it could be removed completely.

I would much rather we do such transforms in the JIT when we know that a given invariant is held, so that the high level managed code can remain easy to understand.
Related issue: #118587

desiredLength should never be negative, this could do with an assert
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Line 330 in 8b10891
intdesiredLength=_length;
We already assume the invariant _length >= 0 holds
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Lines 225 to 230 in 1e322fd
publicMemory<T>Slice(intstart)
{
if((uint)start>(uint)_length)
{
ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument.start);
}

The check here is only to prevent undefined behaviour if the struct is torn, if it wasn't for this it could be removed completely.
Yes, which is necessary/important. The team has a firm stance that we can't rely on users doing safe threading and that we need to do the "right things".
It's the same general reason we have both sets of lengths checks when dealing with List<T> (CC. @GrabYourPitchforks)
We already assume the invariant _length >= 0 holds
It's still something where adding an assert is beneficial as it explicitly documents the expectation.
But, I'd generally rather we have the JIT doing these types of optimizations. The managed code should prefer being readable/understandable first. If something is truly perf critical, then making it less readable with added comments/asserts is ok. However, the JIT automatically recognizing the critical pattern and doing the right thing is even better, as then the code stays readable and other paths likely benefit as well.

xtqqczze · 2025-08-11T15:39:32Z

@MihuBot

MihaZupan · 2025-08-11T15:52:41Z

Changes here overlap with #115275

Clockwork-Muse · 2025-08-11T15:51:35Z

-#else
- if ((uint)desiredStartIndex > (uint)lengthOfUnderlyingSpan || (uint)desiredLength > (uint)lengthOfUnderlyingSpan - (uint)desiredStartIndex)
+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


Yes - it's why the 32-bit target check is written the way it was below (which is a common overflow-avoiding pattern).
We can't "simplify" this, though - the 64 and 32 bit targets are different for a reason; they're taking advantage of different bit widths (or not able to) on different platforms.

tannergooding · 2025-09-16T16:58:21Z

+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


This at least needs a comment explaining why it's safe (that it can't overflow) and should likely do (uint)(desiredStartIndex + desiredLength) instead of (uint)desiredStartIndex + (uint)desiredLength
Additional numbers/info showing the wins would also be beneficial.

// Unsigned overflow cannot occur here because of the following invariants:// desiredStartIndex <= int.MaxValue; as ReadOnlyMemory<T>.RemoveFlagsBitMask == int.MaxValue// desiredLength >= 0; as it is assigned from the _length field which is non-negative by construction// lengthOfUnderlyingSpan >= 0; as it is assigned from the object's Length property which has a non-negative invariant

That seems reasonable. I might put // * desiredStartIndex and similarly for the other 2 listed invariants to help show its part of a list, but I think that fits the need here and covers future readers.

I realised from your comment in the other issue that _length >= 0 may not hold if the struct is torn. Since the condition in question is specifically checking for a torn structure that would be issue without changes to the Slice method.
Ah right, Span<T> is stack only (well non-heap, but anything off the managed heap or stack would have to be a Span<T>* and so unsafe) and the memory model makes it UB to read from/write to the stack of another thread.
Where-as you can have class C { Memory<T> _field; } where one thread reads (objA, index: 5, length: 20) and another thread writes (objB, index: 5, length: 5) in which case a race could exist in Slice(start: 10) such as we get (objB, index: 5, length: -5) because the compare (start > _length) thought it was length: 20 but then the constructed Memory<T> ends up with objB and a length: 5 so we do 5 - 10.
Originally posted by @tannergooding in #119708

Yep, that'd be a risk and might mean this is something that can't be done.
You would need to show if the same thing could be violated via the existing logic and/or if the field was hoisted into a local.

tannergooding · 2025-11-06T18:16:53Z

This is still pending resolution of the comments above and how it preserves the behavior described in the comment

// If the Memory or ReadOnlyMemory instance is torn, this property getter has undefined behavior.
// We try to detect this condition and throw an exception, but it's possible that a torn struct might
// appear to us to be valid, and we'll return an undesired span. Such a span is always guaranteed at
// least to be in-bounds when compared with the original Memory instance, so using the span won't
// AV the process.

If this was a valid transform, the Span<T>.Slice API would likely also be appropriate to update and for similar reasons.

dotnet-policy-service · 2025-12-07T06:07:44Z

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

xtqqczze · 2025-08-11T14:44:43Z

desiredStartIndex cannot be negative as high order bit of _index has been removed.
desiredLength cannot be negative as all public constructors validate _length is not negative.
lengthOfUnderlyingSpan cannot be negative as _object.Length as the length property of an array, string, or span cannot be negative.

dotnet-policy-service · 2025-08-11T14:45:35Z

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

EgorBo · 2025-08-11T15:07:18Z

-#else
- if ((uint)desiredStartIndex > (uint)lengthOfUnderlyingSpan || (uint)desiredLength > (uint)lengthOfUnderlyingSpan - (uint)desiredStartIndex)
+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


if this + overflows the check is passed, isn't ?

desiredLength should never be negative, this could do with an assert
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Line 330 in 8b10891
intdesiredLength=_length;

Yes - it's why the 32-bit target check is written the way it was below (which is a common overflow-avoiding pattern).
We can't "simplify" this, though - the 64 and 32 bit targets are different for a reason; they're taking advantage of different bit widths (or not able to) on different platforms.

This is the kind of thing where the logic is getting even more dense and hard to comprehend
I would much rather we do such transforms in the JIT when we know that a given invariant is held, so that the high level managed code can remain easy to understand.
Otherwise, this needs a significant number of comments and asserts covering those invariants and why the various overflow considerations are "safe" before it could be accepted.

The check here is only to prevent undefined behaviour if the struct is torn, if it wasn't for this it could be removed completely.

I would much rather we do such transforms in the JIT when we know that a given invariant is held, so that the high level managed code can remain easy to understand.
Related issue: #118587

desiredLength should never be negative, this could do with an assert
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Line 330 in 8b10891
intdesiredLength=_length;
We already assume the invariant _length >= 0 holds
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Lines 225 to 230 in 1e322fd
publicMemory<T>Slice(intstart)
{
if((uint)start>(uint)_length)
{
ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument.start);
}

The check here is only to prevent undefined behaviour if the struct is torn, if it wasn't for this it could be removed completely.
Yes, which is necessary/important. The team has a firm stance that we can't rely on users doing safe threading and that we need to do the "right things".
It's the same general reason we have both sets of lengths checks when dealing with List<T> (CC. @GrabYourPitchforks)
We already assume the invariant _length >= 0 holds
It's still something where adding an assert is beneficial as it explicitly documents the expectation.
But, I'd generally rather we have the JIT doing these types of optimizations. The managed code should prefer being readable/understandable first. If something is truly perf critical, then making it less readable with added comments/asserts is ok. However, the JIT automatically recognizing the critical pattern and doing the right thing is even better, as then the code stays readable and other paths likely benefit as well.

xtqqczze · 2025-08-11T15:39:32Z

@MihuBot

MihaZupan · 2025-08-11T15:52:41Z

Changes here overlap with #115275

Clockwork-Muse · 2025-08-11T15:51:35Z

-#else
- if ((uint)desiredStartIndex > (uint)lengthOfUnderlyingSpan || (uint)desiredLength > (uint)lengthOfUnderlyingSpan - (uint)desiredStartIndex)
+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


Yes - it's why the 32-bit target check is written the way it was below (which is a common overflow-avoiding pattern).
We can't "simplify" this, though - the 64 and 32 bit targets are different for a reason; they're taking advantage of different bit widths (or not able to) on different platforms.

tannergooding · 2025-09-16T16:58:21Z

+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


This at least needs a comment explaining why it's safe (that it can't overflow) and should likely do (uint)(desiredStartIndex + desiredLength) instead of (uint)desiredStartIndex + (uint)desiredLength
Additional numbers/info showing the wins would also be beneficial.

// Unsigned overflow cannot occur here because of the following invariants:// desiredStartIndex <= int.MaxValue; as ReadOnlyMemory<T>.RemoveFlagsBitMask == int.MaxValue// desiredLength >= 0; as it is assigned from the _length field which is non-negative by construction// lengthOfUnderlyingSpan >= 0; as it is assigned from the object's Length property which has a non-negative invariant

That seems reasonable. I might put // * desiredStartIndex and similarly for the other 2 listed invariants to help show its part of a list, but I think that fits the need here and covers future readers.

I realised from your comment in the other issue that _length >= 0 may not hold if the struct is torn. Since the condition in question is specifically checking for a torn structure that would be issue without changes to the Slice method.
Ah right, Span<T> is stack only (well non-heap, but anything off the managed heap or stack would have to be a Span<T>* and so unsafe) and the memory model makes it UB to read from/write to the stack of another thread.
Where-as you can have class C { Memory<T> _field; } where one thread reads (objA, index: 5, length: 20) and another thread writes (objB, index: 5, length: 5) in which case a race could exist in Slice(start: 10) such as we get (objB, index: 5, length: -5) because the compare (start > _length) thought it was length: 20 but then the constructed Memory<T> ends up with objB and a length: 5 so we do 5 - 10.
Originally posted by @tannergooding in #119708

Yep, that'd be a risk and might mean this is something that can't be done.
You would need to show if the same thing could be violated via the existing logic and/or if the field was hoisted into a local.

tannergooding · 2025-11-06T18:16:53Z

This is still pending resolution of the comments above and how it preserves the behavior described in the comment

// If the Memory or ReadOnlyMemory instance is torn, this property getter has undefined behavior.
// We try to detect this condition and throw an exception, but it's possible that a torn struct might
// appear to us to be valid, and we'll return an undesired span. Such a span is always guaranteed at
// least to be in-bounds when compared with the original Memory instance, so using the span won't
// AV the process.

If this was a valid transform, the Span<T>.Slice API would likely also be appropriate to update and for similar reasons.

dotnet-policy-service · 2025-12-07T06:07:44Z

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

xtqqczze · 2025-08-11T14:44:43Z

desiredStartIndex cannot be negative as high order bit of _index has been removed.
desiredLength cannot be negative as all public constructors validate _length is not negative.
lengthOfUnderlyingSpan cannot be negative as _object.Length as the length property of an array, string, or span cannot be negative.

dotnet-policy-service · 2025-08-11T14:45:35Z

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

EgorBo · 2025-08-11T15:07:18Z

-#else
- if ((uint)desiredStartIndex > (uint)lengthOfUnderlyingSpan || (uint)desiredLength > (uint)lengthOfUnderlyingSpan - (uint)desiredStartIndex)
+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


if this + overflows the check is passed, isn't ?

desiredLength should never be negative, this could do with an assert
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Line 330 in 8b10891
intdesiredLength=_length;

Yes - it's why the 32-bit target check is written the way it was below (which is a common overflow-avoiding pattern).
We can't "simplify" this, though - the 64 and 32 bit targets are different for a reason; they're taking advantage of different bit widths (or not able to) on different platforms.

This is the kind of thing where the logic is getting even more dense and hard to comprehend
I would much rather we do such transforms in the JIT when we know that a given invariant is held, so that the high level managed code can remain easy to understand.
Otherwise, this needs a significant number of comments and asserts covering those invariants and why the various overflow considerations are "safe" before it could be accepted.

The check here is only to prevent undefined behaviour if the struct is torn, if it wasn't for this it could be removed completely.

I would much rather we do such transforms in the JIT when we know that a given invariant is held, so that the high level managed code can remain easy to understand.
Related issue: #118587

desiredLength should never be negative, this could do with an assert
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Line 330 in 8b10891
intdesiredLength=_length;
We already assume the invariant _length >= 0 holds
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Lines 225 to 230 in 1e322fd
publicMemory<T>Slice(intstart)
{
if((uint)start>(uint)_length)
{
ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument.start);
}

The check here is only to prevent undefined behaviour if the struct is torn, if it wasn't for this it could be removed completely.
Yes, which is necessary/important. The team has a firm stance that we can't rely on users doing safe threading and that we need to do the "right things".
It's the same general reason we have both sets of lengths checks when dealing with List<T> (CC. @GrabYourPitchforks)
We already assume the invariant _length >= 0 holds
It's still something where adding an assert is beneficial as it explicitly documents the expectation.
But, I'd generally rather we have the JIT doing these types of optimizations. The managed code should prefer being readable/understandable first. If something is truly perf critical, then making it less readable with added comments/asserts is ok. However, the JIT automatically recognizing the critical pattern and doing the right thing is even better, as then the code stays readable and other paths likely benefit as well.

xtqqczze · 2025-08-11T15:39:32Z

@MihuBot

MihaZupan · 2025-08-11T15:52:41Z

Changes here overlap with #115275

Clockwork-Muse · 2025-08-11T15:51:35Z

-#else
- if ((uint)desiredStartIndex > (uint)lengthOfUnderlyingSpan || (uint)desiredLength > (uint)lengthOfUnderlyingSpan - (uint)desiredStartIndex)
+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


Yes - it's why the 32-bit target check is written the way it was below (which is a common overflow-avoiding pattern).
We can't "simplify" this, though - the 64 and 32 bit targets are different for a reason; they're taking advantage of different bit widths (or not able to) on different platforms.

tannergooding · 2025-09-16T16:58:21Z

+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


This at least needs a comment explaining why it's safe (that it can't overflow) and should likely do (uint)(desiredStartIndex + desiredLength) instead of (uint)desiredStartIndex + (uint)desiredLength
Additional numbers/info showing the wins would also be beneficial.

// Unsigned overflow cannot occur here because of the following invariants:// desiredStartIndex <= int.MaxValue; as ReadOnlyMemory<T>.RemoveFlagsBitMask == int.MaxValue// desiredLength >= 0; as it is assigned from the _length field which is non-negative by construction// lengthOfUnderlyingSpan >= 0; as it is assigned from the object's Length property which has a non-negative invariant

That seems reasonable. I might put // * desiredStartIndex and similarly for the other 2 listed invariants to help show its part of a list, but I think that fits the need here and covers future readers.

I realised from your comment in the other issue that _length >= 0 may not hold if the struct is torn. Since the condition in question is specifically checking for a torn structure that would be issue without changes to the Slice method.
Ah right, Span<T> is stack only (well non-heap, but anything off the managed heap or stack would have to be a Span<T>* and so unsafe) and the memory model makes it UB to read from/write to the stack of another thread.
Where-as you can have class C { Memory<T> _field; } where one thread reads (objA, index: 5, length: 20) and another thread writes (objB, index: 5, length: 5) in which case a race could exist in Slice(start: 10) such as we get (objB, index: 5, length: -5) because the compare (start > _length) thought it was length: 20 but then the constructed Memory<T> ends up with objB and a length: 5 so we do 5 - 10.
Originally posted by @tannergooding in #119708

Yep, that'd be a risk and might mean this is something that can't be done.
You would need to show if the same thing could be violated via the existing logic and/or if the field was hoisted into a local.

tannergooding · 2025-11-06T18:16:53Z

This is still pending resolution of the comments above and how it preserves the behavior described in the comment

// If the Memory or ReadOnlyMemory instance is torn, this property getter has undefined behavior.
// We try to detect this condition and throw an exception, but it's possible that a torn struct might
// appear to us to be valid, and we'll return an undesired span. Such a span is always guaranteed at
// least to be in-bounds when compared with the original Memory instance, so using the span won't
// AV the process.

If this was a valid transform, the Span<T>.Slice API would likely also be appropriate to update and for similar reasons.

dotnet-policy-service · 2025-12-07T06:07:44Z

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

xtqqczze · 2025-08-11T14:44:43Z

desiredStartIndex cannot be negative as high order bit of _index has been removed.
desiredLength cannot be negative as all public constructors validate _length is not negative.
lengthOfUnderlyingSpan cannot be negative as _object.Length as the length property of an array, string, or span cannot be negative.

dotnet-policy-service · 2025-08-11T14:45:35Z

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

EgorBo · 2025-08-11T15:07:18Z

-#else
- if ((uint)desiredStartIndex > (uint)lengthOfUnderlyingSpan || (uint)desiredLength > (uint)lengthOfUnderlyingSpan - (uint)desiredStartIndex)
+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


if this + overflows the check is passed, isn't ?

desiredLength should never be negative, this could do with an assert
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Line 330 in 8b10891
intdesiredLength=_length;

Yes - it's why the 32-bit target check is written the way it was below (which is a common overflow-avoiding pattern).
We can't "simplify" this, though - the 64 and 32 bit targets are different for a reason; they're taking advantage of different bit widths (or not able to) on different platforms.

This is the kind of thing where the logic is getting even more dense and hard to comprehend
I would much rather we do such transforms in the JIT when we know that a given invariant is held, so that the high level managed code can remain easy to understand.
Otherwise, this needs a significant number of comments and asserts covering those invariants and why the various overflow considerations are "safe" before it could be accepted.

The check here is only to prevent undefined behaviour if the struct is torn, if it wasn't for this it could be removed completely.

I would much rather we do such transforms in the JIT when we know that a given invariant is held, so that the high level managed code can remain easy to understand.
Related issue: #118587

desiredLength should never be negative, this could do with an assert
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Line 330 in 8b10891
intdesiredLength=_length;
We already assume the invariant _length >= 0 holds
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Lines 225 to 230 in 1e322fd
publicMemory<T>Slice(intstart)
{
if((uint)start>(uint)_length)
{
ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument.start);
}

The check here is only to prevent undefined behaviour if the struct is torn, if it wasn't for this it could be removed completely.
Yes, which is necessary/important. The team has a firm stance that we can't rely on users doing safe threading and that we need to do the "right things".
It's the same general reason we have both sets of lengths checks when dealing with List<T> (CC. @GrabYourPitchforks)
We already assume the invariant _length >= 0 holds
It's still something where adding an assert is beneficial as it explicitly documents the expectation.
But, I'd generally rather we have the JIT doing these types of optimizations. The managed code should prefer being readable/understandable first. If something is truly perf critical, then making it less readable with added comments/asserts is ok. However, the JIT automatically recognizing the critical pattern and doing the right thing is even better, as then the code stays readable and other paths likely benefit as well.

xtqqczze · 2025-08-11T15:39:32Z

@MihuBot

MihaZupan · 2025-08-11T15:52:41Z

Changes here overlap with #115275

Clockwork-Muse · 2025-08-11T15:51:35Z

-#else
- if ((uint)desiredStartIndex > (uint)lengthOfUnderlyingSpan || (uint)desiredLength > (uint)lengthOfUnderlyingSpan - (uint)desiredStartIndex)
+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


Yes - it's why the 32-bit target check is written the way it was below (which is a common overflow-avoiding pattern).
We can't "simplify" this, though - the 64 and 32 bit targets are different for a reason; they're taking advantage of different bit widths (or not able to) on different platforms.

tannergooding · 2025-09-16T16:58:21Z

+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


This at least needs a comment explaining why it's safe (that it can't overflow) and should likely do (uint)(desiredStartIndex + desiredLength) instead of (uint)desiredStartIndex + (uint)desiredLength
Additional numbers/info showing the wins would also be beneficial.

// Unsigned overflow cannot occur here because of the following invariants:// desiredStartIndex <= int.MaxValue; as ReadOnlyMemory<T>.RemoveFlagsBitMask == int.MaxValue// desiredLength >= 0; as it is assigned from the _length field which is non-negative by construction// lengthOfUnderlyingSpan >= 0; as it is assigned from the object's Length property which has a non-negative invariant

That seems reasonable. I might put // * desiredStartIndex and similarly for the other 2 listed invariants to help show its part of a list, but I think that fits the need here and covers future readers.

I realised from your comment in the other issue that _length >= 0 may not hold if the struct is torn. Since the condition in question is specifically checking for a torn structure that would be issue without changes to the Slice method.
Ah right, Span<T> is stack only (well non-heap, but anything off the managed heap or stack would have to be a Span<T>* and so unsafe) and the memory model makes it UB to read from/write to the stack of another thread.
Where-as you can have class C { Memory<T> _field; } where one thread reads (objA, index: 5, length: 20) and another thread writes (objB, index: 5, length: 5) in which case a race could exist in Slice(start: 10) such as we get (objB, index: 5, length: -5) because the compare (start > _length) thought it was length: 20 but then the constructed Memory<T> ends up with objB and a length: 5 so we do 5 - 10.
Originally posted by @tannergooding in #119708

Yep, that'd be a risk and might mean this is something that can't be done.
You would need to show if the same thing could be violated via the existing logic and/or if the field was hoisted into a local.

tannergooding · 2025-11-06T18:16:53Z

This is still pending resolution of the comments above and how it preserves the behavior described in the comment

// If the Memory or ReadOnlyMemory instance is torn, this property getter has undefined behavior.
// We try to detect this condition and throw an exception, but it's possible that a torn struct might
// appear to us to be valid, and we'll return an undesired span. Such a span is always guaranteed at
// least to be in-bounds when compared with the original Memory instance, so using the span won't
// AV the process.

If this was a valid transform, the Span<T>.Slice API would likely also be appropriate to update and for similar reasons.

dotnet-policy-service · 2025-12-07T06:07:44Z

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

xtqqczze · 2025-08-11T14:44:43Z

desiredStartIndex cannot be negative as high order bit of _index has been removed.
desiredLength cannot be negative as all public constructors validate _length is not negative.
lengthOfUnderlyingSpan cannot be negative as _object.Length as the length property of an array, string, or span cannot be negative.

dotnet-policy-service · 2025-08-11T14:45:35Z

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

EgorBo · 2025-08-11T15:07:18Z

-#else
- if ((uint)desiredStartIndex > (uint)lengthOfUnderlyingSpan || (uint)desiredLength > (uint)lengthOfUnderlyingSpan - (uint)desiredStartIndex)
+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


if this + overflows the check is passed, isn't ?

desiredLength should never be negative, this could do with an assert
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Line 330 in 8b10891
intdesiredLength=_length;

Yes - it's why the 32-bit target check is written the way it was below (which is a common overflow-avoiding pattern).
We can't "simplify" this, though - the 64 and 32 bit targets are different for a reason; they're taking advantage of different bit widths (or not able to) on different platforms.

This is the kind of thing where the logic is getting even more dense and hard to comprehend
I would much rather we do such transforms in the JIT when we know that a given invariant is held, so that the high level managed code can remain easy to understand.
Otherwise, this needs a significant number of comments and asserts covering those invariants and why the various overflow considerations are "safe" before it could be accepted.

The check here is only to prevent undefined behaviour if the struct is torn, if it wasn't for this it could be removed completely.

I would much rather we do such transforms in the JIT when we know that a given invariant is held, so that the high level managed code can remain easy to understand.
Related issue: #118587

desiredLength should never be negative, this could do with an assert
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Line 330 in 8b10891
intdesiredLength=_length;
We already assume the invariant _length >= 0 holds
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Lines 225 to 230 in 1e322fd
publicMemory<T>Slice(intstart)
{
if((uint)start>(uint)_length)
{
ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument.start);
}

The check here is only to prevent undefined behaviour if the struct is torn, if it wasn't for this it could be removed completely.
Yes, which is necessary/important. The team has a firm stance that we can't rely on users doing safe threading and that we need to do the "right things".
It's the same general reason we have both sets of lengths checks when dealing with List<T> (CC. @GrabYourPitchforks)
We already assume the invariant _length >= 0 holds
It's still something where adding an assert is beneficial as it explicitly documents the expectation.
But, I'd generally rather we have the JIT doing these types of optimizations. The managed code should prefer being readable/understandable first. If something is truly perf critical, then making it less readable with added comments/asserts is ok. However, the JIT automatically recognizing the critical pattern and doing the right thing is even better, as then the code stays readable and other paths likely benefit as well.

xtqqczze · 2025-08-11T15:39:32Z

@MihuBot

MihaZupan · 2025-08-11T15:52:41Z

Changes here overlap with #115275

Clockwork-Muse · 2025-08-11T15:51:35Z

-#else
- if ((uint)desiredStartIndex > (uint)lengthOfUnderlyingSpan || (uint)desiredLength > (uint)lengthOfUnderlyingSpan - (uint)desiredStartIndex)
+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


Yes - it's why the 32-bit target check is written the way it was below (which is a common overflow-avoiding pattern).
We can't "simplify" this, though - the 64 and 32 bit targets are different for a reason; they're taking advantage of different bit widths (or not able to) on different platforms.

tannergooding · 2025-09-16T16:58:21Z

+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


This at least needs a comment explaining why it's safe (that it can't overflow) and should likely do (uint)(desiredStartIndex + desiredLength) instead of (uint)desiredStartIndex + (uint)desiredLength
Additional numbers/info showing the wins would also be beneficial.

// Unsigned overflow cannot occur here because of the following invariants:// desiredStartIndex <= int.MaxValue; as ReadOnlyMemory<T>.RemoveFlagsBitMask == int.MaxValue// desiredLength >= 0; as it is assigned from the _length field which is non-negative by construction// lengthOfUnderlyingSpan >= 0; as it is assigned from the object's Length property which has a non-negative invariant

That seems reasonable. I might put // * desiredStartIndex and similarly for the other 2 listed invariants to help show its part of a list, but I think that fits the need here and covers future readers.

I realised from your comment in the other issue that _length >= 0 may not hold if the struct is torn. Since the condition in question is specifically checking for a torn structure that would be issue without changes to the Slice method.
Ah right, Span<T> is stack only (well non-heap, but anything off the managed heap or stack would have to be a Span<T>* and so unsafe) and the memory model makes it UB to read from/write to the stack of another thread.
Where-as you can have class C { Memory<T> _field; } where one thread reads (objA, index: 5, length: 20) and another thread writes (objB, index: 5, length: 5) in which case a race could exist in Slice(start: 10) such as we get (objB, index: 5, length: -5) because the compare (start > _length) thought it was length: 20 but then the constructed Memory<T> ends up with objB and a length: 5 so we do 5 - 10.
Originally posted by @tannergooding in #119708

Yep, that'd be a risk and might mean this is something that can't be done.
You would need to show if the same thing could be violated via the existing logic and/or if the field was hoisted into a local.

tannergooding · 2025-11-06T18:16:53Z

This is still pending resolution of the comments above and how it preserves the behavior described in the comment

// If the Memory or ReadOnlyMemory instance is torn, this property getter has undefined behavior.
// We try to detect this condition and throw an exception, but it's possible that a torn struct might
// appear to us to be valid, and we'll return an undesired span. Such a span is always guaranteed at
// least to be in-bounds when compared with the original Memory instance, so using the span won't
// AV the process.

If this was a valid transform, the Span<T>.Slice API would likely also be appropriate to update and for similar reasons.

dotnet-policy-service · 2025-12-07T06:07:44Z

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

xtqqczze · 2025-08-11T14:44:43Z

desiredStartIndex cannot be negative as high order bit of _index has been removed.
desiredLength cannot be negative as all public constructors validate _length is not negative.
lengthOfUnderlyingSpan cannot be negative as _object.Length as the length property of an array, string, or span cannot be negative.

dotnet-policy-service · 2025-08-11T14:45:35Z

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

EgorBo · 2025-08-11T15:07:18Z

-#else
- if ((uint)desiredStartIndex > (uint)lengthOfUnderlyingSpan || (uint)desiredLength > (uint)lengthOfUnderlyingSpan - (uint)desiredStartIndex)
+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


if this + overflows the check is passed, isn't ?

desiredLength should never be negative, this could do with an assert
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Line 330 in 8b10891
intdesiredLength=_length;

Yes - it's why the 32-bit target check is written the way it was below (which is a common overflow-avoiding pattern).
We can't "simplify" this, though - the 64 and 32 bit targets are different for a reason; they're taking advantage of different bit widths (or not able to) on different platforms.

This is the kind of thing where the logic is getting even more dense and hard to comprehend
I would much rather we do such transforms in the JIT when we know that a given invariant is held, so that the high level managed code can remain easy to understand.
Otherwise, this needs a significant number of comments and asserts covering those invariants and why the various overflow considerations are "safe" before it could be accepted.

The check here is only to prevent undefined behaviour if the struct is torn, if it wasn't for this it could be removed completely.

I would much rather we do such transforms in the JIT when we know that a given invariant is held, so that the high level managed code can remain easy to understand.
Related issue: #118587

desiredLength should never be negative, this could do with an assert
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Line 330 in 8b10891
intdesiredLength=_length;
We already assume the invariant _length >= 0 holds
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Lines 225 to 230 in 1e322fd
publicMemory<T>Slice(intstart)
{
if((uint)start>(uint)_length)
{
ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument.start);
}

The check here is only to prevent undefined behaviour if the struct is torn, if it wasn't for this it could be removed completely.
Yes, which is necessary/important. The team has a firm stance that we can't rely on users doing safe threading and that we need to do the "right things".
It's the same general reason we have both sets of lengths checks when dealing with List<T> (CC. @GrabYourPitchforks)
We already assume the invariant _length >= 0 holds
It's still something where adding an assert is beneficial as it explicitly documents the expectation.
But, I'd generally rather we have the JIT doing these types of optimizations. The managed code should prefer being readable/understandable first. If something is truly perf critical, then making it less readable with added comments/asserts is ok. However, the JIT automatically recognizing the critical pattern and doing the right thing is even better, as then the code stays readable and other paths likely benefit as well.

xtqqczze · 2025-08-11T15:39:32Z

@MihuBot

MihaZupan · 2025-08-11T15:52:41Z

Changes here overlap with #115275

Clockwork-Muse · 2025-08-11T15:51:35Z

-#else
- if ((uint)desiredStartIndex > (uint)lengthOfUnderlyingSpan || (uint)desiredLength > (uint)lengthOfUnderlyingSpan - (uint)desiredStartIndex)
+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


Yes - it's why the 32-bit target check is written the way it was below (which is a common overflow-avoiding pattern).
We can't "simplify" this, though - the 64 and 32 bit targets are different for a reason; they're taking advantage of different bit widths (or not able to) on different platforms.

tannergooding · 2025-09-16T16:58:21Z

+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


This at least needs a comment explaining why it's safe (that it can't overflow) and should likely do (uint)(desiredStartIndex + desiredLength) instead of (uint)desiredStartIndex + (uint)desiredLength
Additional numbers/info showing the wins would also be beneficial.

// Unsigned overflow cannot occur here because of the following invariants:// desiredStartIndex <= int.MaxValue; as ReadOnlyMemory<T>.RemoveFlagsBitMask == int.MaxValue// desiredLength >= 0; as it is assigned from the _length field which is non-negative by construction// lengthOfUnderlyingSpan >= 0; as it is assigned from the object's Length property which has a non-negative invariant

That seems reasonable. I might put // * desiredStartIndex and similarly for the other 2 listed invariants to help show its part of a list, but I think that fits the need here and covers future readers.

I realised from your comment in the other issue that _length >= 0 may not hold if the struct is torn. Since the condition in question is specifically checking for a torn structure that would be issue without changes to the Slice method.
Ah right, Span<T> is stack only (well non-heap, but anything off the managed heap or stack would have to be a Span<T>* and so unsafe) and the memory model makes it UB to read from/write to the stack of another thread.
Where-as you can have class C { Memory<T> _field; } where one thread reads (objA, index: 5, length: 20) and another thread writes (objB, index: 5, length: 5) in which case a race could exist in Slice(start: 10) such as we get (objB, index: 5, length: -5) because the compare (start > _length) thought it was length: 20 but then the constructed Memory<T> ends up with objB and a length: 5 so we do 5 - 10.
Originally posted by @tannergooding in #119708

Yep, that'd be a risk and might mean this is something that can't be done.
You would need to show if the same thing could be violated via the existing logic and/or if the field was hoisted into a local.

tannergooding · 2025-11-06T18:16:53Z

This is still pending resolution of the comments above and how it preserves the behavior described in the comment

// If the Memory or ReadOnlyMemory instance is torn, this property getter has undefined behavior.
// We try to detect this condition and throw an exception, but it's possible that a torn struct might
// appear to us to be valid, and we'll return an undesired span. Such a span is always guaranteed at
// least to be in-bounds when compared with the original Memory instance, so using the span won't
// AV the process.

If this was a valid transform, the Span<T>.Slice API would likely also be appropriate to update and for similar reasons.

dotnet-policy-service · 2025-12-07T06:07:44Z

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

xtqqczze · 2025-08-11T14:44:43Z

desiredStartIndex cannot be negative as high order bit of _index has been removed.
desiredLength cannot be negative as all public constructors validate _length is not negative.
lengthOfUnderlyingSpan cannot be negative as _object.Length as the length property of an array, string, or span cannot be negative.

dotnet-policy-service · 2025-08-11T14:45:35Z

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

EgorBo · 2025-08-11T15:07:18Z

-#else
- if ((uint)desiredStartIndex > (uint)lengthOfUnderlyingSpan || (uint)desiredLength > (uint)lengthOfUnderlyingSpan - (uint)desiredStartIndex)
+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


if this + overflows the check is passed, isn't ?

desiredLength should never be negative, this could do with an assert
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Line 330 in 8b10891
intdesiredLength=_length;

Yes - it's why the 32-bit target check is written the way it was below (which is a common overflow-avoiding pattern).
We can't "simplify" this, though - the 64 and 32 bit targets are different for a reason; they're taking advantage of different bit widths (or not able to) on different platforms.

This is the kind of thing where the logic is getting even more dense and hard to comprehend
I would much rather we do such transforms in the JIT when we know that a given invariant is held, so that the high level managed code can remain easy to understand.
Otherwise, this needs a significant number of comments and asserts covering those invariants and why the various overflow considerations are "safe" before it could be accepted.

The check here is only to prevent undefined behaviour if the struct is torn, if it wasn't for this it could be removed completely.

I would much rather we do such transforms in the JIT when we know that a given invariant is held, so that the high level managed code can remain easy to understand.
Related issue: #118587

desiredLength should never be negative, this could do with an assert
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Line 330 in 8b10891
intdesiredLength=_length;
We already assume the invariant _length >= 0 holds
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Lines 225 to 230 in 1e322fd
publicMemory<T>Slice(intstart)
{
if((uint)start>(uint)_length)
{
ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument.start);
}

The check here is only to prevent undefined behaviour if the struct is torn, if it wasn't for this it could be removed completely.
Yes, which is necessary/important. The team has a firm stance that we can't rely on users doing safe threading and that we need to do the "right things".
It's the same general reason we have both sets of lengths checks when dealing with List<T> (CC. @GrabYourPitchforks)
We already assume the invariant _length >= 0 holds
It's still something where adding an assert is beneficial as it explicitly documents the expectation.
But, I'd generally rather we have the JIT doing these types of optimizations. The managed code should prefer being readable/understandable first. If something is truly perf critical, then making it less readable with added comments/asserts is ok. However, the JIT automatically recognizing the critical pattern and doing the right thing is even better, as then the code stays readable and other paths likely benefit as well.

xtqqczze · 2025-08-11T15:39:32Z

@MihuBot

MihaZupan · 2025-08-11T15:52:41Z

Changes here overlap with #115275

Clockwork-Muse · 2025-08-11T15:51:35Z

-#else
- if ((uint)desiredStartIndex > (uint)lengthOfUnderlyingSpan || (uint)desiredLength > (uint)lengthOfUnderlyingSpan - (uint)desiredStartIndex)
+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


Yes - it's why the 32-bit target check is written the way it was below (which is a common overflow-avoiding pattern).
We can't "simplify" this, though - the 64 and 32 bit targets are different for a reason; they're taking advantage of different bit widths (or not able to) on different platforms.

tannergooding · 2025-09-16T16:58:21Z

+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


This at least needs a comment explaining why it's safe (that it can't overflow) and should likely do (uint)(desiredStartIndex + desiredLength) instead of (uint)desiredStartIndex + (uint)desiredLength
Additional numbers/info showing the wins would also be beneficial.

// Unsigned overflow cannot occur here because of the following invariants:// desiredStartIndex <= int.MaxValue; as ReadOnlyMemory<T>.RemoveFlagsBitMask == int.MaxValue// desiredLength >= 0; as it is assigned from the _length field which is non-negative by construction// lengthOfUnderlyingSpan >= 0; as it is assigned from the object's Length property which has a non-negative invariant

That seems reasonable. I might put // * desiredStartIndex and similarly for the other 2 listed invariants to help show its part of a list, but I think that fits the need here and covers future readers.

I realised from your comment in the other issue that _length >= 0 may not hold if the struct is torn. Since the condition in question is specifically checking for a torn structure that would be issue without changes to the Slice method.
Ah right, Span<T> is stack only (well non-heap, but anything off the managed heap or stack would have to be a Span<T>* and so unsafe) and the memory model makes it UB to read from/write to the stack of another thread.
Where-as you can have class C { Memory<T> _field; } where one thread reads (objA, index: 5, length: 20) and another thread writes (objB, index: 5, length: 5) in which case a race could exist in Slice(start: 10) such as we get (objB, index: 5, length: -5) because the compare (start > _length) thought it was length: 20 but then the constructed Memory<T> ends up with objB and a length: 5 so we do 5 - 10.
Originally posted by @tannergooding in #119708

Yep, that'd be a risk and might mean this is something that can't be done.
You would need to show if the same thing could be violated via the existing logic and/or if the field was hoisted into a local.

tannergooding · 2025-11-06T18:16:53Z

This is still pending resolution of the comments above and how it preserves the behavior described in the comment

// If the Memory or ReadOnlyMemory instance is torn, this property getter has undefined behavior.
// We try to detect this condition and throw an exception, but it's possible that a torn struct might
// appear to us to be valid, and we'll return an undesired span. Such a span is always guaranteed at
// least to be in-bounds when compared with the original Memory instance, so using the span won't
// AV the process.

If this was a valid transform, the Span<T>.Slice API would likely also be appropriate to update and for similar reasons.

dotnet-policy-service · 2025-12-07T06:07:44Z

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

xtqqczze · 2025-08-11T14:44:43Z

desiredStartIndex cannot be negative as high order bit of _index has been removed.
desiredLength cannot be negative as all public constructors validate _length is not negative.
lengthOfUnderlyingSpan cannot be negative as _object.Length as the length property of an array, string, or span cannot be negative.

dotnet-policy-service · 2025-08-11T14:45:35Z

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

EgorBo · 2025-08-11T15:07:18Z

-#else
- if ((uint)desiredStartIndex > (uint)lengthOfUnderlyingSpan || (uint)desiredLength > (uint)lengthOfUnderlyingSpan - (uint)desiredStartIndex)
+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


if this + overflows the check is passed, isn't ?

desiredLength should never be negative, this could do with an assert
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Line 330 in 8b10891
intdesiredLength=_length;

Yes - it's why the 32-bit target check is written the way it was below (which is a common overflow-avoiding pattern).
We can't "simplify" this, though - the 64 and 32 bit targets are different for a reason; they're taking advantage of different bit widths (or not able to) on different platforms.

This is the kind of thing where the logic is getting even more dense and hard to comprehend
I would much rather we do such transforms in the JIT when we know that a given invariant is held, so that the high level managed code can remain easy to understand.
Otherwise, this needs a significant number of comments and asserts covering those invariants and why the various overflow considerations are "safe" before it could be accepted.

The check here is only to prevent undefined behaviour if the struct is torn, if it wasn't for this it could be removed completely.

I would much rather we do such transforms in the JIT when we know that a given invariant is held, so that the high level managed code can remain easy to understand.
Related issue: #118587

desiredLength should never be negative, this could do with an assert
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Line 330 in 8b10891
intdesiredLength=_length;
We already assume the invariant _length >= 0 holds
runtime/src/libraries/System.Private.CoreLib/src/System/Memory.cs
Lines 225 to 230 in 1e322fd
publicMemory<T>Slice(intstart)
{
if((uint)start>(uint)_length)
{
ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument.start);
}

The check here is only to prevent undefined behaviour if the struct is torn, if it wasn't for this it could be removed completely.
Yes, which is necessary/important. The team has a firm stance that we can't rely on users doing safe threading and that we need to do the "right things".
It's the same general reason we have both sets of lengths checks when dealing with List<T> (CC. @GrabYourPitchforks)
We already assume the invariant _length >= 0 holds
It's still something where adding an assert is beneficial as it explicitly documents the expectation.
But, I'd generally rather we have the JIT doing these types of optimizations. The managed code should prefer being readable/understandable first. If something is truly perf critical, then making it less readable with added comments/asserts is ok. However, the JIT automatically recognizing the critical pattern and doing the right thing is even better, as then the code stays readable and other paths likely benefit as well.

xtqqczze · 2025-08-11T15:39:32Z

@MihuBot

MihaZupan · 2025-08-11T15:52:41Z

Changes here overlap with #115275

Clockwork-Muse · 2025-08-11T15:51:35Z

-#else
- if ((uint)desiredStartIndex > (uint)lengthOfUnderlyingSpan || (uint)desiredLength > (uint)lengthOfUnderlyingSpan - (uint)desiredStartIndex)
+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


Yes - it's why the 32-bit target check is written the way it was below (which is a common overflow-avoiding pattern).
We can't "simplify" this, though - the 64 and 32 bit targets are different for a reason; they're taking advantage of different bit widths (or not able to) on different platforms.

tannergooding · 2025-09-16T16:58:21Z

+ Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
+ if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)


This at least needs a comment explaining why it's safe (that it can't overflow) and should likely do (uint)(desiredStartIndex + desiredLength) instead of (uint)desiredStartIndex + (uint)desiredLength
Additional numbers/info showing the wins would also be beneficial.

// Unsigned overflow cannot occur here because of the following invariants:// desiredStartIndex <= int.MaxValue; as ReadOnlyMemory<T>.RemoveFlagsBitMask == int.MaxValue// desiredLength >= 0; as it is assigned from the _length field which is non-negative by construction// lengthOfUnderlyingSpan >= 0; as it is assigned from the object's Length property which has a non-negative invariant

That seems reasonable. I might put // * desiredStartIndex and similarly for the other 2 listed invariants to help show its part of a list, but I think that fits the need here and covers future readers.

I realised from your comment in the other issue that _length >= 0 may not hold if the struct is torn. Since the condition in question is specifically checking for a torn structure that would be issue without changes to the Slice method.
Ah right, Span<T> is stack only (well non-heap, but anything off the managed heap or stack would have to be a Span<T>* and so unsafe) and the memory model makes it UB to read from/write to the stack of another thread.
Where-as you can have class C { Memory<T> _field; } where one thread reads (objA, index: 5, length: 20) and another thread writes (objB, index: 5, length: 5) in which case a race could exist in Slice(start: 10) such as we get (objB, index: 5, length: -5) because the compare (start > _length) thought it was length: 20 but then the constructed Memory<T> ends up with objB and a length: 5 so we do 5 - 10.
Originally posted by @tannergooding in #119708

Yep, that'd be a risk and might mean this is something that can't be done.
You would need to show if the same thing could be violated via the existing logic and/or if the field was hoisted into a local.

tannergooding · 2025-11-06T18:16:53Z

This is still pending resolution of the comments above and how it preserves the behavior described in the comment

// If the Memory or ReadOnlyMemory instance is torn, this property getter has undefined behavior.
// We try to detect this condition and throw an exception, but it's possible that a torn struct might
// appear to us to be valid, and we'll return an undesired span. Such a span is always guaranteed at
// least to be in-bounds when compared with the original Memory instance, so using the span won't
// AV the process.

If this was a valid transform, the Span<T>.Slice API would likely also be appropriate to update and for similar reasons.

dotnet-policy-service · 2025-12-07T06:07:44Z

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

Simplify range validation in Memory.Span
ba5473a

github-actionsBot added the area-System.Memory label Aug 11, 2025

dotnet-policy-serviceBot added the community-contribution Indicates that the PR has been added by a community member label Aug 11, 2025

EgorBo reviewed Aug 11, 2025
View reviewed changes

MihuBot mentioned this pull request Aug 11, 2025
[JitDiff X64] [xtqqczze] Simplify range validation in Memory.SpanMihuBot/runtime-utils#1369
Open

Clockwork-Muse reviewed Aug 11, 2025
View reviewed changes

jeffhandley assigned tannergooding Sep 2, 2025

tannergooding reviewed Sep 16, 2025
View reviewed changes

xtqqczze marked this pull request as draft November 6, 2025 19:32

dotnet-policy-serviceBot closed this Dec 7, 2025

github-actionsBot locked and limited conversation to collaborators Jan 6, 2026

Simplify range validation in Memory.Span
ba5473a

github-actionsBot added the area-System.Memory label Aug 11, 2025

dotnet-policy-serviceBot added the community-contribution Indicates that the PR has been added by a community member label Aug 11, 2025

EgorBo reviewed Aug 11, 2025
View reviewed changes

MihuBot mentioned this pull request Aug 11, 2025
[JitDiff X64] [xtqqczze] Simplify range validation in Memory.SpanMihuBot/runtime-utils#1369
Open

Clockwork-Muse reviewed Aug 11, 2025
View reviewed changes

jeffhandley assigned tannergooding Sep 2, 2025

tannergooding reviewed Sep 16, 2025
View reviewed changes

xtqqczze marked this pull request as draft November 6, 2025 19:32

dotnet-policy-serviceBot closed this Dec 7, 2025

github-actionsBot locked and limited conversation to collaborators Jan 6, 2026

Simplify range validation in Memory.Span
ba5473a

github-actionsBot added the area-System.Memory label Aug 11, 2025

dotnet-policy-serviceBot added the community-contribution Indicates that the PR has been added by a community member label Aug 11, 2025

EgorBo reviewed Aug 11, 2025
View reviewed changes

MihuBot mentioned this pull request Aug 11, 2025
[JitDiff X64] [xtqqczze] Simplify range validation in Memory.SpanMihuBot/runtime-utils#1369
Open

Clockwork-Muse reviewed Aug 11, 2025
View reviewed changes

jeffhandley assigned tannergooding Sep 2, 2025

tannergooding reviewed Sep 16, 2025
View reviewed changes

xtqqczze marked this pull request as draft November 6, 2025 19:32

dotnet-policy-serviceBot closed this Dec 7, 2025

github-actionsBot locked and limited conversation to collaborators Jan 6, 2026

Simplify range validation in Memory.Span
ba5473a

github-actionsBot added the area-System.Memory label Aug 11, 2025

dotnet-policy-serviceBot added the community-contribution Indicates that the PR has been added by a community member label Aug 11, 2025

EgorBo reviewed Aug 11, 2025
View reviewed changes

MihuBot mentioned this pull request Aug 11, 2025
[JitDiff X64] [xtqqczze] Simplify range validation in Memory.SpanMihuBot/runtime-utils#1369
Open

Clockwork-Muse reviewed Aug 11, 2025
View reviewed changes

jeffhandley assigned tannergooding Sep 2, 2025

tannergooding reviewed Sep 16, 2025
View reviewed changes

xtqqczze marked this pull request as draft November 6, 2025 19:32

dotnet-policy-serviceBot closed this Dec 7, 2025

github-actionsBot locked and limited conversation to collaborators Jan 6, 2026

Simplify range validation in Memory.Span
ba5473a

github-actionsBot added the area-System.Memory label Aug 11, 2025

dotnet-policy-serviceBot added the community-contribution Indicates that the PR has been added by a community member label Aug 11, 2025

EgorBo reviewed Aug 11, 2025
View reviewed changes

MihuBot mentioned this pull request Aug 11, 2025
[JitDiff X64] [xtqqczze] Simplify range validation in Memory.SpanMihuBot/runtime-utils#1369
Open

Clockwork-Muse reviewed Aug 11, 2025
View reviewed changes

jeffhandley assigned tannergooding Sep 2, 2025

tannergooding reviewed Sep 16, 2025
View reviewed changes

xtqqczze marked this pull request as draft November 6, 2025 19:32

dotnet-policy-serviceBot closed this Dec 7, 2025

github-actionsBot locked and limited conversation to collaborators Jan 6, 2026

Simplify range validation in Memory.Span
ba5473a

github-actionsBot added the area-System.Memory label Aug 11, 2025

dotnet-policy-serviceBot added the community-contribution Indicates that the PR has been added by a community member label Aug 11, 2025

EgorBo reviewed Aug 11, 2025
View reviewed changes

MihuBot mentioned this pull request Aug 11, 2025
[JitDiff X64] [xtqqczze] Simplify range validation in Memory.SpanMihuBot/runtime-utils#1369
Open

Clockwork-Muse reviewed Aug 11, 2025
View reviewed changes

jeffhandley assigned tannergooding Sep 2, 2025

tannergooding reviewed Sep 16, 2025
View reviewed changes

xtqqczze marked this pull request as draft November 6, 2025 19:32

dotnet-policy-serviceBot closed this Dec 7, 2025

github-actionsBot locked and limited conversation to collaborators Jan 6, 2026

Simplify range validation in Memory.Span
ba5473a

github-actionsBot added the area-System.Memory label Aug 11, 2025

dotnet-policy-serviceBot added the community-contribution Indicates that the PR has been added by a community member label Aug 11, 2025

EgorBo reviewed Aug 11, 2025
View reviewed changes

MihuBot mentioned this pull request Aug 11, 2025
[JitDiff X64] [xtqqczze] Simplify range validation in Memory.SpanMihuBot/runtime-utils#1369
Open

Clockwork-Muse reviewed Aug 11, 2025
View reviewed changes

jeffhandley assigned tannergooding Sep 2, 2025

tannergooding reviewed Sep 16, 2025
View reviewed changes

xtqqczze marked this pull request as draft November 6, 2025 19:32

dotnet-policy-serviceBot closed this Dec 7, 2025

github-actionsBot locked and limited conversation to collaborators Jan 6, 2026

Simplify range validation in Memory.Span
ba5473a

github-actionsBot added the area-System.Memory label Aug 11, 2025

dotnet-policy-serviceBot added the community-contribution Indicates that the PR has been added by a community member label Aug 11, 2025

EgorBo reviewed Aug 11, 2025
View reviewed changes

MihuBot mentioned this pull request Aug 11, 2025
[JitDiff X64] [xtqqczze] Simplify range validation in Memory.SpanMihuBot/runtime-utils#1369
Open

Clockwork-Muse reviewed Aug 11, 2025
View reviewed changes

jeffhandley assigned tannergooding Sep 2, 2025

tannergooding reviewed Sep 16, 2025
View reviewed changes

xtqqczze marked this pull request as draft November 6, 2025 19:32

dotnet-policy-serviceBot closed this Dec 7, 2025

github-actionsBot locked and limited conversation to collaborators Jan 6, 2026

	publicMemory<T>Slice(intstart)
	{
	if((uint)start>(uint)_length)
	{
	ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument.start);
	}

		Debug.Assert((int)desiredStartIndex >= 0 && lengthOfUnderlyingSpan >= 0);
		if ((uint)desiredStartIndex + (uint)desiredLength > (uint)lengthOfUnderlyingSpan)

Uh oh!

Conversation

xtqqczze commented Aug 11, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-serviceBot commented Aug 11, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xtqqczze commented Aug 11, 2025

Uh oh!

MihaZupan commented Aug 11, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tannergooding commented Nov 6, 2025

Uh oh!

dotnet-policy-serviceBot commented Dec 7, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

xtqqczze commented Aug 11, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-serviceBot commented Aug 11, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xtqqczze commented Aug 11, 2025

Uh oh!

MihaZupan commented Aug 11, 2025

Uh oh!

Choose a reason for hiding this comment

xtqqczze commented Aug 11, 2025•
edited
Loading

xtqqczze commented Aug 11, 2025•
edited
Loading

xtqqczze commented Aug 11, 2025•
edited
Loading