sizeof(T) and T* for reference type T work

[GeeLaw]

The current sizeof documentation and pointer type documentation say they can only be applied to unmanaged types. To quote:

The sizeof operator returns the number of bytes occupied by a variable of a given type. The argument to the sizeof operator must be the name of an unmanaged type or a type parameter that is constrained to be an unmanaged type.

The type specified before the * in a pointer type is called the referent type. Only an unmanaged type can be a referent type.

However, csc (Microsoft (R) Visual C# Compiler version 4.8.0-7.23558.1 (e0917286)) actually accepts the following code:

static class Program
{
  public static unsafe void Main()
  {
    object o = "Hello,";
    object* p = &o;
    Console.WriteLine(o);
    *p = "world!";
    Console.WriteLine(o);
    Console.WriteLine(sizeof(object));
  }
}

Unsurprisingly, on 64-bit platforms, it outputs

Hello,
world!
8

or ... 4 on 32-bit platforms.

Whose bug? But it's good.

Is this a bug of the compiler (which must become feature as it's been widely available), or is this a bug of the documentation? It appears to be the former case, because the ECMA version (December 2023) also doesn't allow sizeof(T) or T* for non-unmanaged types.

The current behavior is entirely expected and sometimes needed. For example,

// default is Sequential layout
public readonly struct ValidUtf16
{
  public readonly string Value;
  public ValidUtf16(string s)
  {
    // Somehow check s is valid UTF-16 and throw otherwise.
    Value = s;
  }
}

public static unsafe class ValidUtf16Extensions
{
  static ValidUtf16Extensions()
  {
    if (sizeof(ValidUtf16) != sizeof(string))
    {
      throw new Exception("Code in this class relies on sizeof(ValidUtf16) == sizeof(string)");
    }
  }
  public static ReadOnlySpan<string> AsStrings(this Span<ValidUtf16> that)
  {
    return MemoryMarshal.CreateReadOnlySpan(
      ref Unsafe.As<ValidUtf16, string>(ref MemoryMarshal.GetReference(that)),
      that.Length);
  }
}

In the example above, ValidUtf16 is a wrapper of string intended to only contain valid UTF-16 sequences. Suppose we have a Span<ValidUtf16>, we want to be able to reinterpret it as a ReadOnlySpan<string> and preserve type safety. For that to happen, we must ensure that a ValidUtf16 is exactly of the size of a string.

Runtime's perspective

Reading ECMA-335 (CLI) Edition 6... Of course, sizeof (CIL instruction) has always supported reference types.

From II.14.4 （pointer types), the runtime indeed supports T* for reference type T --- T* is an unmanaged pointer, where "unmanaged" means the pointer is untracked by GC, different from the meaning of "unmanaged" in "unmanaged types".

From II.15.5.4 (data type marshaling), to quote,

The following data types shall be marshaled by all conforming implementations of the CLI...

• ...
• The type string.
• Unmanaged pointers to any of the above types.

It suggests that the runtime is expected to see string*.

More on the docs

Regarding the documentation text (in unsafe-code.md):

A pointer can't point to a reference or to a struct that contains references, because an object reference can be garbage collected even if a pointer is pointing to it.

This is logically incorrect.

1. Pointer only appears in unsafe contexts, which means we are explicitly leaving verifiability behind. Therefore, the danger of GC moving things around is fine.
2. If the pointer is acquired by "normal" C# (i.e., & of short-lived variables, i.e., on the evaluation stack, or fixed; not by *(void**)Unsafe.AsPointer(ref o)), then there's no issue between the pointer and the garbage collector. A short-lived variable, by virtue of being allowed to be taken address of without fixed, must have been allocated at an unmovable location (which is usually the thread execution stack --- but as Eric Lippert says, it could have been allocated on the managed heap, in which case I expect the C# compiler to pin it for me). A pointer acquired from fixed statement of course pins the object.

Summary

Currently, the C# compiler accepts sizeof(T) and T* for reference type T in unsafe code. This is a bug of the compiler or a bug of the docs, but either way, this behavior is useful and should be preserved. There are also some other problems with the docs. I suggest:

• Update the documentation and the ECMA C# spec to allow sizeof(T) and T* for reference type T.
• Review the documentation for illogical statements and revise them.

[huoyaoyuan]

The spec is not "current". It's for a quite old language version. The specialization work is left behind from language development for about 5 years.
There's no bug here. It's new feature in C# 11 and documented at https://github.com/dotnet/csharplang/blob/main/proposals/csharp-11.0/low-level-struct-improvements.md#changes-in-unsafe-context . The current language spec is close to complete for C# 8.

[GeeLaw]

There's spec (either draft or ECMA), docs (language reference is not language specification), and implementation. I thought the docs were current, not the spec, but I guess the docs aren't current either. The language reference should be updated?

I tried searching for sizeof in the directory you linked to but couldn't find it. In pointer arithmetic definition, the text uses sizeof(T) for T*, where T might be reference types now, so it'll need to be defined for the proposal docs to be consistent.

[huoyaoyuan]

Yes, the language design documentation is not as detailed as ECMA specification. That's why specification is a standalone work at https://github.com/dotnet/csharpstandard .
The C# language reference documentation is also updated separately. Since this feature wasn't included in What's new in C# 11, maybe it's forgotten.

[jnm2]

@GeeLaw Since this just an issue of the docs not yet being up to date, would you please use the "Open a documentation issue" link at the bottom of one of the docs pages (e.g. https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/sizeof)? You can mention both pages in the same docs issue.

[GeeLaw]

Linking: dotnet/docs#44137

[jnm2]

Excellent, thanks for contributing so much legwork!