Bugzilla – Bug 8448
`sizeof` IL opcode doesn't behave properly with respect to reference types
Last modified: 2012-11-17 04:15:11 EST
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:
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
Fixed in master.