Unify semantics of `cpblk` and `initblk` of zero size between Mono and CoreCLR

[SingleAccretion]

It was discovered in a CI run (Mono monointerpreter Pri0 Runtime Tests Run OSX x64 release) that (at least when using the interpreter) Mono throws a NullReferenceException when executing a cpblk with a size of zero (I suspect it is the same for initblk).

Reproduction:

using System;
using System.Runtime.CompilerServices;

Console.WriteLine(TestCpBlk(ref Unsafe.NullRef<byte>(), ref Unsafe.NullRef<byte>(), 0));

[MethodImpl(MethodImplOptions.NoInlining)]
static bool TestCpBlk(ref byte dst, ref byte src, uint size)
{
    Unsafe.CopyBlock(ref dst, ref src, size);

    return Unsafe.AreSame(ref dst, ref Unsafe.NullRef<byte>());
}

In ECMA 335, III.3.30 cpblk/III.3.36 initblk, we can find under Exceptions:

System.NullReferenceException can be thrown if an invalid address is detected.

Suggesting that both throwing and not throwing are legal behaviors (and they both seem reasonable). But it would be nice to have the two runtimes behave the same.

Tagging subscribers to this area: @BrzVlad
See info in area-owners.md if you want to be subscribed.

Issue Details

---

It was discovered in a CI run (Mono monointerpreter Pri0 Runtime Tests Run OSX x64 release) that (at least when using the interpreter) Mono throws a NullReferenceException when executing a cpblk with a size of zero (I suspect it is the same for initblk).

Reproduction:

using System;
using System.Runtime.CompilerServices;

Console.WriteLine(TestCpBlk(ref Unsafe.NullRef<byte>(), ref Unsafe.NullRef<byte>(), 0));

[MethodImpl(MethodImplOptions.NoInlining)]
static bool TestCpBlk(ref byte dst, ref byte src, uint size)
{
    Unsafe.CopyBlock(ref dst, ref src, size);

    return Unsafe.AreSame(ref dst, ref Unsafe.NullRef<byte>());
}

In ECMA 335, III.3.30 cpblk/III.3.36 initblk, we can find under Exceptions:

System.NullReferenceException can be thrown if an invalid address is detected.

Suggesting that both throwing and not throwing are legal behaviors (and they both seem reasonable). But it would be nice to have the two runtimes behave the same.

Author:	SingleAccretion
Assignees:	-
Labels:	area-Codegen-Interpreter-mono
Milestone:	-

[jkotas]

Managed C++ is the heavy user of the initblk/cpblk opcodes. It uses it as memset/memcpy. memset/memcpy works fine for null pointer and zero size. Notice that the spec for these opcodes exactly matches the spec for memset/memcpy. Throwing exception in CoreCLR would be a hard to justify breaking change.

I think we should fix Mono to stop throwing for null pointer and zero size for these opcodes.

Also delete

runtime/src/libraries/System.Private.CoreLib/src/System/Span.cs

Line 287 in 895c99c

#if MONO

once this is fixed.

[lambdageek]

I think we should fix Mono to stop throwing for null pointer and zero size for these opcodes.

As far as I can tell, this is just a Mono interpreter issue. The JIT (and AOT) does not throw in this case (verified by inspecting method-to-ir.c and also by running a repro .csproj, below).

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <RuntimeIdentifier>osx-x64</RuntimeIdentifier>
    <SelfContained>true</SelfContained>
    <UseMonoRuntime>true</UseMonoRuntime>
  </PropertyGroup>

</Project>

test with

$ dotnet run
True
$ MONO_ENV_OPTIONS=--interp dotnet run

Unhandled Exception:
System.NullReferenceException: Object reference not set to an instance of an object.
   at Program.<<Main>$>g__TestCpBlk|0_0(Byte& dst, Byte& src, UInt32 size) in /private/tmp/CpblkTest/Program.cs:line 9
   at Program.<Main>$(String[] args) in /private/tmp/CpblkTest/Program.cs:line 4
[ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object.
   at Program.<<Main>$>g__TestCpBlk|0_0(Byte& dst, Byte& src, UInt32 size) in /private/tmp/CpblkTest/Program.cs:line 9
   at Program.<Main>$(String[] args) in /private/tmp/CpblkTest/Program.cs:line 4

/cc @BrzVlad

[lambdageek]

It was discovered in a CI run (Mono monointerpreter Pri0 Runtime Tests Run OSX x64 release) that (at least when using the interpreter)

@SingleAccretion is there a disabled test?

[SingleAccretion]

@lambdageek not a merged one - I hit it over at #63026, and will re-enable the test once #63086 is in.