In my previous
post, I described the role of System.Void in the .NET framework and demonstrated
some of the restrictions placed on the type.
In this post, I’ll postulate why those restrictions are in place and I’ll
try to bypass them in an attempt to create an instance of the type.
The restrictions on the System.Void type are documented in the Common Language Infrastructure (CLI) specification (ECMA-335)
.
I find two of these restrictions particularly interesting:
“The type System.Void is never boxable.” (Section 8.2.4)
“No location or value shall have System.Void” (Section 8.7)
Why is instantiation of the System.Void type forbidden? After all, as long as methods
are not allowed to declare a return type of System.Void, the purpose of the type
as discussed in my previous post remains intact, regardless of whether instances
are allowed to exist or not.
So, what’s the harm in permitting instances of this type to exist? I proffer
the following explanations.
Firstly, from a philosophical standpoint, it doesn’t make much sense to have
the ability to instantiate a type that methods cannot declare as a return type,
because that is effectively saying that you can create this object but your methods
cannot pass its value (unless in a boxed representation or masqueraded as an inherited
type) around.
Secondly, some unexpected issues can arise when calling methods declared in generic
types. For example, if developers can instantiate System.Void, they’ll expect
to be able to compile and run the following code, but by so doing produce a method
that has a System.Void return type.
class Program
{
static void Main(string[] args)
{
var instance = new MyClass<System.Void>().GetInstance();
}
}
class MyClass<T> where T:new()
{
public T GetInstance()
{
return new T();
}
}
The compiler/runtime can be updated to prevent such code from compiling or running,
however it’s cleaner to have a rule that states that System.Void cannot be
instantiated and that the expression “System.Void” is illegal anywhere
in C#.
The last explanation I proffer has to do with pointers in C#, and I think it is
the most functional explanation.
You can get the System.Type object of a value type pointer with the following
expression:
typeof(MyStruct*)
For example:
typeof(int*)
evaluates to a System.Type object called
System.Int32*
Similarly, typeof(bool*), typeof(DateTime*), typeof(char*) and typeof(System.Guid*)
will evaluate to System.Type objects called System.Boolean*,
System.DateTime*, System.Char* and System.Guid*
respectively.
Now, there is a special kind of pointer called the void pointer which can point to any pointer type.
The type declaration for a void pointer is void*, and the following
expression gets the System.Type object of a void pointer:
typeof(void*)
It evaluates to a System.Type object called
System.Void*
You can already see how an ambiguity is introduced if instances of System.Void were
allowed to exist.
In that scenario, typeof(System.Void*) would evaluate to a System.Type object also
called System.Void*.
It would be impossible (or at least error-prone) to tell if the object is for a
pointer to System.Void or for the special void pointer.
Nevertheless, and in spite of my failed attempts to instantiate System.Void in the
previous post, it is possible to create an instance of System.Void -- by making it
a static field.
// Metadata version: v2.0.50727
.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
.ver 2:0:0:0
}
.assembly ConsoleApplication1
{
.hash algorithm 0x00008004
.ver 1:0:0:0
}
.module ConsoleApplication1.exe
// MVID: {60F1E74C-3123-4EF0-8269-A0C3B8B85ADF}
.imagebase 0x00400000
.file alignment 0x00000200
.stackreserve 0x00100000
.subsystem 0x0003 // WINDOWS_CUI
.corflags 0x00000001 // ILONLY
// Image base: 0x00670000
// =============== CLASS MEMBERS DECLARATION ===================
.class private auto ansi beforefieldinit Program
extends [mscorlib]System.Object
{
.field public static valuetype [mscorlib]System.Void o
.method private hidebysig static void Main() cil managed
{
.entrypoint
// Code size 1 (0x1)
.maxstack 8
IL_0000: ret
} // end of method Program::Main
.method public hidebysig specialname rtspecialname
instance void .ctor() cil managed
{
// Code size 7 (0x7)
.maxstack 8
IL_0000: ldarg.0
IL_0001: call instance void [mscorlib]System.Object::.ctor()
IL_0006: ret
} // end of method Program::.ctor
} // end of class Program
The IL code listing above is equivalent to the following C# program (if it were possible to
compile)
class Program
{
public static System.Void o;
static void Main()
{
}
}
If I compile the IL code using ilasm and run it, I don’t observe any errors, unlike
in my previous attempts.
What does this mean? Did it create an instance of the type? Is the runtime skipping
over that System.Void field creation instruction? Is the program dying silently?
This is a good example of the "If a tree falls in a forest and no one is around to hear it, does
it make a sound?" philosophical riddle.
What I need is some observability. I need to be absolutely sure that the type was
instantiated (or not).
I’ll just modify the code a little bit to get some output:
class Program
{
public static System.Void o;
static void Main()
{
Console.WriteLine(o.ToString());
}
}
which translates to the following IL code:
// Metadata version: v2.0.50727
.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
.ver 2:0:0:0
}
.assembly ConsoleApplication1
{
.hash algorithm 0x00008004
.ver 1:0:0:0
}
.module ConsoleApplication1.exe
// MVID: {EE60F7FD-BD3D-46C8-B353-A459F5119496}
.imagebase 0x00400000
.file alignment 0x00000200
.stackreserve 0x00100000
.subsystem 0x0003 // WINDOWS_CUI
.corflags 0x00000001 // ILONLY
// Image base: 0x00260000
// =============== CLASS MEMBERS DECLARATION ===================
.class private auto ansi beforefieldinit Program
extends [mscorlib]System.Object
{
.field public static valuetype [mscorlib]System.Void o
.method private hidebysig static void Main() cil managed
{
.entrypoint
// Code size 22 (0x16)
.maxstack 8
IL_0000: ldsflda valuetype [mscorlib]System.Void Program::o
IL_0005: constrained. [mscorlib]System.Void
IL_000b: callvirt instance string [mscorlib]System.Object::ToString()
IL_0010: call void [mscorlib]System.Console::WriteLine(string)
IL_0015: ret
} // end of method Program::Main
.method public hidebysig specialname rtspecialname
instance void .ctor() cil managed
{
// Code size 7 (0x7)
.maxstack 8
IL_0000: ldarg.0
IL_0001: call instance void [mscorlib]System.Object::.ctor()
IL_0006: ret
} // end of method Program::.ctor
} // end of class Program
If I run the program, I get a fatal InvalidProgramException error
message. The issue is that ToString() is defined on the base System.Object
class. When I call System.Void.ToString(), the runtime boxes the value type to an
object before calling the ToString() method.
Remember that rule which states that System.Void cannot be boxed. It is enforced
by the runtime. There is a check that the value is not System.Void during boxing,
and if the check fails, the program is halted.
|
On a side note, this is another good reason to avoid boxing whenever possible.
There is some overhead, besides copying the value to the boxed representation, due to many type checks.
|
System.Void does not define any members that we can access. The other members
(GetType(), ToString(), GetHashCode(), etc.) are all inherited. Calling the inherited
methods will lead to boxing which is prohibited. How can we observe its existence?
There’s one way.
// Metadata version: v2.0.50727
.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
.ver 2:0:0:0
}
.assembly MultiVoid
{
.permissionset reqmin
= {[mscorlib]System.Security.Permissions.SecurityPermissionAttribute = {property bool 'SkipVerification' = bool(true)}}
.hash algorithm 0x00008004
.ver 1:0:0:0
}
.module MultiVoid.exe
// MVID: {AC411515-B789-4594-B52B-1EC2668D16C9}
.custom instance void [mscorlib]System.Security.UnverifiableCodeAttribute::.ctor() = ( 01 00 00 00 )
.imagebase 0x00400000
.file alignment 0x00000200
.stackreserve 0x00100000
.subsystem 0x0003 // WINDOWS_CUI
.corflags 0x00000001 // ILONLY
// Image base: 0x00BC0000
// =============== CLASS MEMBERS DECLARATION ===================
.class private auto ansi beforefieldinit Program
extends [mscorlib]System.Object
{
.field public static valuetype [mscorlib]System.Void o
.field public static valuetype [mscorlib]System.Void p
.method private hidebysig static void Main() cil managed
{
.entrypoint
// Code size 35 (0x23)
.maxstack 1
.locals init (valuetype [mscorlib]System.Void& pinned V_0,
valuetype [mscorlib]System.Void& pinned V_1)
IL_0000: ldsflda valuetype [mscorlib]System.Void Program::o
IL_0005: stloc.0
IL_0006: ldloc.0
IL_0007: conv.i
IL_0008: conv.i4
IL_0009: call void [mscorlib]System.Console::WriteLine(int32)
IL_000e: ldc.i4.0
IL_000f: conv.u
IL_0010: stloc.0
IL_0011: ldsflda valuetype [mscorlib]System.Void Program::p
IL_0016: stloc.1
IL_0017: ldloc.1
IL_0018: conv.i
IL_0019: conv.i4
IL_001a: call void [mscorlib]System.Console::WriteLine(int32)
IL_001f: ldc.i4.0
IL_0020: conv.u
IL_0021: stloc.1
IL_0022: ret
} // end of method Program::Main
.method public hidebysig specialname rtspecialname
instance void .ctor() cil managed
{
// Code size 7 (0x7)
.maxstack 8
IL_0000: ldarg.0
IL_0001: call instance void [mscorlib]System.Object::.ctor()
IL_0006: ret
} // end of method Program::.ctor
} // end of class Program
The IL code above translates to the following uncompilable C# code:
class Program
{
public static System.Void o;
public static System.Void p;
static void Main()
{
unsafe
{
fixed (System.Void* i = &o)
{
Console.WriteLine((int)i);
}
fixed (System.Void* j = &p)
{
Console.WriteLine((int)j);
}
}
}
}
It displays the addresses of the System.Void instances in memory: If you run the IL
code, you’ll see an output with the memory addresses of the two instances
like as shown below:
Congratulations! You just created two instances of the forbidden System.Void type!
That may be as far as you may go. The runtime will detect attempts to place the
instance on the evaluation stack, which is necessary to return the instance value
from a method.