In 2010 I wrote the blog post Fun with pointers in C#. Back then, I thought it was fun. Today, I am not so sure. Lets take a look at the following code fragment:
using System; namespace ClassLibrary1 { public class Class1 { unsafe public void Method1(ref object* obj) { Console.WriteLine(obj->ToString()); } } }
If you try to compile this code with C# compiler distributed with .NET 1.1 you will get the following error:
error CS1005: Indirection to managed type is not valid
This is all good and nice because error CS1005 is aligned with the C# language specification which states:
Unlike references (values of reference types), pointers are not tracked by the garbage collector—the garbage collector has no knowledge of pointers and the data to which they point. For this reason a pointer is not permitted to point to a reference or to a struct that contains references, and the referent type of a pointer must be an unmanaged-type.
An unmanaged-type is any type that isn’t a reference-type or constructed type, and doesn’t contain reference-type or constructed type fields at any level of nesting. In other words, an unmanaged-type is one of the following:
sbyte, byte, short, ushort, int, uint, long, ulong, char, float, double, decimal, or bool.
Any enum-type.
Any pointer-type.
Any user-defined struct-type that is not a constructed type and contains fields of unmanaged-types only.
However since .NET 2.0 Microsoft introduced a bug that allows you to compile the code fragment above. Currently, I use C# compiler version 4.0.30319.17929 and I can still compile the code. If you run peverify.exe tool on the produced assembly you will get the following error:
[IL]: Error: [ClassLibrary1.dll : ClassLibrary1.Class1::Method1][offset 0x00000001] Unmanaged pointers are not a verifiable type. 1 Error(s) Verifying ClassLibrary1.dll
Mono C# compiler (version 3.0.6) does it right. It fails, as expected, with error CS0208:
Class1.cs(7,40): error CS0208: Cannot take the address of, get the size of, or declare a pointer to a managed type `object'
Considering the fact that .NET 2.0 was released in 2005 it is hard to believe that Microsoft has not fixed the bug for the last 7 years. The only explanation I have here is that the bug is quite esoteric.