[Mono-dev] Is the `sizeof` opcode doing the right thing?

[Robert Jordan]

On 14.11.2012 04:04, Jordan Earls wrote:
> Hi, I've been messing with building a rather low-level datastructure
> to avoid the Large Object Heap.
>
> One thing this required of me was to write a very small library
> directly in IL. The function I implemented is this:
>
>      .method public static hidebysig
>             default int32 SizeOf<T> ()  cil managed
>      {
>          .maxstack 1
> 	sizeof !!T
>           ret
>      }

Have you verified this code with PEVerify under MS.NET?

> 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"
>
> I think that language is a tiny bit ambiguous. Basically, does this
> mean mono is being correct in that it's storing a "reference value" as
> the entire class(an optimization?), or is Mono doing the wrong thing
> in not returning just the size of the pointer? I'm not sure about the
> Mono internals or anything, so I suspect that it *might* be conforming
> to the spec, but I'd really like if someone could verify for this for
> me.

According to BCL's specs, OpCodes.Sizeof only applies to
value types:

http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.sizeof%28v=vs.110%29.aspx

The C# sizeof operator doesn't allow reference types either.

Robert