在C＃/ .NET中，为什么sbyte []与byte []相同，除非它不是？

Question

I just observed a weird phenomenon in C#/.NET.

I created this minimal example to demonstrate:

if (new sbyte[5] is byte[])
{
 throw new ApplicationException("Impossible!");
}

object o = new sbyte[5];

if (o is byte[])
{
 throw new ApplicationException("Why???");
}

This will throw "Why???", but not "Impossible!". It works for all arrays of integral types of the same size. Can someone explain this to me? I'm confused. I'm using .NET 4 by the way.

PS: I know that I can get the expected result by using o.GetType() == typeof(byte[]) .

Answer 1

The CLR rules of casting specify that this is possible. The C# rules say it is not possible. The C# team consciously decided that they would tolerate this deviation from the spec for various reasons.

Why does the CLR allow this? Probably because they can conveniently implement it. byte and sbyte have the same binary representation so you can "treat" a byte[] as an sbyte[] without violating memory safety .

The same trick works for other primitive types with the same memory layout.

Answer 2

Funny, I got bitten by that in my question, Why does this Linq Cast Fail when using ToList?

Jon Skeet (of course) explains that my problem is the C# compiler, for whatever reason, thinks they could never be the same thing, and helpfully optimizes it to false. However, the CLR does let this happen. The cast to object throws off the compiler optimization, so it goes through the CLR.

The relevant part from his answer :

Even though in C# you can't cast a byte[] to an sbyte[] directly, the CLR allows it:

var foo = new byte[] {246, 127};
// This produces a warning at compile-time, and the C# compiler "optimizes"
// to the constant "false"
Console.WriteLine(foo is sbyte[]);

object x = foo;
// Using object fools the C# compiler into really consulting the CLR... which
// allows the conversion, so this prints True
Console.WriteLine(x is sbyte[]);

---

Joel asked an interesting question in the comments, "Is this behavior controlled by the Optimize Code flag ( /o to the compiler)?"

Given this code:

static void Main(string[] args)
{
    sbyte[] baz = new sbyte[0];
    Console.WriteLine(baz is byte[]);
}

And compiled with csc /o- Code.cs (don't optimize), it appears that the compiler optimizes it anyway. The resulting IL:

IL_0000:  nop
IL_0001:  ldc.i4.0
IL_0002:  newarr     [mscorlib]System.SByte
IL_0007:  stloc.0
IL_0008:  ldc.i4.0
IL_0009:  call       void [mscorlib]System.Console::WriteLine(bool)
IL_000e:  nop
IL_000f:  ret

IL_0008 loads 0 (false) directly onto the stack, then calls WriteLine on IL_0009. So no, the optimization flag does not make a difference. If the CLR were to be consulted, the isinst instruction would get used. It would probably look something like this starting from IL_0008:

IL_0008:  ldloc.0
IL_0009:  isinst     uint8[]
IL_000e:  ldnull
IL_000f:  cgt.un
IL_0011:  call       void [mscorlib]System.Console::WriteLine(bool)

I would agree with the optimizer's behavior. The optimization flag should not change the behavior of your program.

Answer 3

VB.NET actually "throws" at compile time:

Expression of type '1-dimensional array of SByte' can never be of type '1-dimensional array of Byte'.

on the equivalent of the first if statement.

And the equivalent of the second if succeeds (ie it throws the coded exception) at runtime as expected because it is the same CLR.

Answer 4

Here's a simpler example that shows the same issue:

static void Main(string[] args)
{
    bool a = ((object) new byte[0]) is sbyte[];
    bool b = (new byte[0]) is sbyte[];

    Console.WriteLine(a == b); // False
}

The inconsistency arises because the C# compiler decides that it knows the result of (new byte[0]) is sbyte[] at compile time, and just substitutes false . Perhaps it should really substitute true , to be more consistent with the CLR behaviour.

As far as I can tell, it's only this little optimization that's inconsistent. It occurs only when both sides of the is expression are statically typed as an array whose element type is a signed or unsigned integer or an enum, and the sizes of the integers are the same.

The good news is that while this might seem inconsistent, C# will always issue a warning when it substitutes false into such expressions – in practice, I think this might be more useful than quietly returning true .