Created attachment 2953 [details]
compiled test case
I believe I've found a bug concerning the `sizeof` opcode in Mono's IL implementation. Note: I'm NOT talking about the C# `sizeof()` operator.
I made a tiny library in IL that has this method:
.method public static hidebysig
default int32 SizeOf<T> () cil managed
And then I tested it with:
public static void Main (string args)
int a, b;
The output from this program is rather surprising for the sizeof Bar. Here is the full output (on my 64-bit machine):
I posted about this issue in the mailing list, but was told to look here: http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.sizeof%28v=vs.95%29.aspx
That link appears to indicate my IL is invalid, but it does verify. I believe that page is flat-out wrong also. In the ECMA spec, on page 423 for partition III, it says "For a reference type, the size returned is the size of a reference value to the corresponding type, not the size of the data stored in objects referred to by a reference value"
Unless Mono is doing some really weird "inlining" of classes into value-types, then Mono is doing it wrong. This can cause a lot of problems because the sizeof opcode was created so that pointer arithmetic with arrays is possible with structures as the elements of the array.
For reference, on .Net I get the expected value of either 4 or 8 for the size of "Bar" when running the program there (depends on platform of course)
Created attachment 2954 [details]
sizeof IL library (required to run example program)
The pages are identical, but here is the link to the actual .Net framework doc(not silverlight): http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.sizeof%28v=vs.110%29.aspx
Fixed in master.