В C# есть четыре ключевых слова, которых нет в документации. Компилятор их принимает.

Одно из них собирается на любой машине, а выполняется только на Windows. На Linux та же сборка падает. Дальше — как объект меняет свой тип на ходу и что на самом деле происходит при вызове метода у пустой ссылки.

Проверено на четырёх машинах x64 под Windows, на .NET 8, 9 и 10, сборки от 8.0.11 до 10.0.12.

1. makeref, reftype, __refvalue

Исходник

__makeref создаёт TypedReference — пару из указателя на данные и указателя на тип. __reftype возвращает тип из этой пары, __refvalue читает и пишет значение.

int number = 42;
string text = "Секрет";
 
TypedReference toNumber = __makeref(number);
TypedReference toText = __makeref(text);
 
Console.WriteLine(__reftype(toNumber).Name);   // Int32
Console.WriteLine(__reftype(toText).Name);     // String
 
__refvalue(toNumber, int) = 100;
Console.WriteLine(number);                     // 100

Тип TypedReference в документации есть. __makeref, __reftype и __refvalue — нет.

Что выводит отчёт

Тип переменной без вызова GetType
 
  int       __reftype даёт Int32
  string    __reftype даёт String
  DateTime  __reftype даёт DateTime
 
Разница с GetType
 
  число до записи: 42
  после __refvalue: 100
  TypedReference.ToObject: Секрет

Одинаково на .NET 8, 9 и 10 и на всех четырёх машинах.

Причина

GetType работает с объектом. Для значимого типа это означает упаковку: значение сначала попадает в кучу и только потом возвращает свой тип.

__reftype работает с переменной. Тип берётся из второй половины TypedReference, куда его записал __makeref, и в кучу ничего не попадает.

Так же устроена и запись через __refvalue: в паре хранится указатель на саму переменную, а не копия значения. В строке __refvalue(toNumber, int) = 100; переменная number не названа, а меняется именно она.

Где легко ошибиться

TypedReference — это ref struct, и отсюда все запреты: его нельзя сохранить в поле, положить в массив или передать в асинхронный метод. Он существует только на стеке и только в пределах вызова, потому что внутри хранит прямой указатель на переменную.

Где встречается

В рефлексии. Методы FieldInfo.SetValueDirect и GetValueDirect принимают TypedReference: через них можно записать поле структуры, не упаковывая её в объект. Обычный SetValue принимает object, то есть упакованную копию, и запись уходит в неё, а не в исходную структуру.

__reftype вызывается внутри TypedReference.GetHashCode: иначе тип оттуда не получить.

2. Собирается везде, работает только на Windows

Исходник

__arglist объявляет метод с переменным числом аргументов без params и без массива. Аргументы перечисляются через ArgIterator:

private static string Join(__arglist)
{
    ArgIterator iterator = new(__arglist);
    string result = string.Empty;
 
    while (iterator.GetRemainingCount() > 0)
    {
        TypedReference argument = iterator.GetNextArg();
        result += __reftype(argument).Name + " = "
                + TypedReference.ToObject(argument) + "; ";
    }
 
    return result;
}
 
// вызов
Join(__arglist(1, "два", 3.5));

Сборка проходит без единого предупреждения.

Что выводит отчёт

Система: Microsoft Windows 10.0.17763, X64
 
  вызов прошёл: Int32 = 1; String = два; Double = 3,5;

Та же сборка на Linux:

Система: Ubuntu 24.04.4 LTS, X64
 
  вызов не прошёл
  тип исключения: System.InvalidProgramException
  сообщение:      Vararg calling convention not supported.

Причина

Всё решает одна проверка в джите:

// Native Varargs are not supported on Unix (all architectures) and Windows ARM
inline bool compFeatureVarArg()
{
    return TargetOS::IsWindows && !TargetArchitecture::IsArm32;
}

Когда она не выполняется, джит отказывается компилировать вызов:

if (!compFeatureVarArg() && ((sig->callConv & CORINFO_CALLCONV_MASK) == CORINFO_CALLCONV_VARARG ||
                             (sig->callConv & CORINFO_CALLCONV_MASK) == CORINFO_CALLCONV_NATIVEVARARG))
{
    BADCODE("Varargs not supported.");
}

Джит проверяет соглашение вызова не тогда, когда компилирует метод с __arglist, а тогда, когда компилирует метод, откуда его вызывают. Поэтому падает вызывающий код, а не сам метод.

Соглашение вызова с переменным числом аргументов пришло из C, и на Unix его в .NET не реализовали.

Где легко ошибиться

Вызов нужно вынести в отдельный метод и поставить над ним [MethodImpl(MethodImplOptions.NoInlining)]. Джит компилирует метод целиком, поэтому при встроенном вызове он откажется от всего метода, куда тот попал, и программа упадёт до первой выведенной строки — даже если вызов обёрнут в try.

Метод с __arglist нельзя объявить в обобщённом типе: среда выполнения такое не собирает.

Где встречается

Поиск по исходникам .NET не находит ни одного метода с __arglist. Оно существует ради соглашения вызова из стандарта CLI: другие компиляторы под эту платформу умеют выдавать такой код, и рантайм должен его выполнять. На Unix этого не сделали.

3. Массив уверен, что он строка

Исходник

У объекта в куче перед данными идут два служебных поля по 8 байт: заголовок для блока синхронизации и указатель на таблицу методов. Сама таблица описана на C# структурой с явными смещениями. Если записать в это место указатель на таблицу другого типа, рантайм начнёт считать объект этим типом:

nint original = MethodTable(numbers);
 
SetMethodTable(numbers, MethodTable(sample));
Console.WriteLine(numbers.GetType());
SetMethodTable(numbers, original);

Что выводит отчёт

До замены
  массив отвечает: System.Int32[]
  строка отвечает: System.String
 
После замены
  массив отвечает: System.String
  содержимое как строка: ..o   (длина 3)
 
После возврата
  массив отвечает: System.Int32[]
  первый элемент:  111
  сборка мусора прошла, куча цела

Причина

Массив создан из трёх чисел: 111, 222, 333. Сразу за указателем на таблицу методов у строки записана длина в четырёх байтах, а у массива под длину отведено восемь. Строка прочитала первые четыре байта и получила длину 3.

Символы строка читает сразу за своими четырьмя байтами длины. Там у массива ещё не данные, а оставшиеся четыре байта его длины, и в них нули: отсюда два первых символа, которые отчёт заменил точками. Третий символ приходится уже на первое число массива: 111, а код 111 в Юникоде — латинская o.

Где легко ошибиться

Объект с заменённой таблицей существует ровно две строки. Замена и возврат идут в одном методе, между ними нет ни выхода, ни вызова сборки мусора. Если оставить объект в таком виде, сборщик мусора прочитает его поля по описанию чужого типа и уронит процесс.

Отчёт после возврата вызывает сборку мусора и убеждается, что процесс не упал. Тот же отчёт снят и на серверном сборщике: он размещает объекты иначе.

Где встречается

В библиотеке .NET такой замены нет, и польза от неё только одна: понять, из чего собран объект. Похожим приёмом пользуются отладчики и профилировщики, которым нужно прочитать чужой объект, не вызывая его методов.

4. Объект вместо условия

Исходник

Операторы true и false перегружаются как обычные операторы, но только парой:

public static bool operator true(Flag flag) => flag._value;
public static bool operator false(Flag flag) => !flag._value;
 
public static Flag operator &(Flag left, Flag right)
    => new(left._value && right._value);

После этого объект можно написать в условии вместо bool, хотя приведения к bool у типа нет.

Что выводит отчёт

  if (yes)                сработал
  if (no)                 не сработал
  while с объектом        оборотов 3
  тернарный оператор      ветка да
 
  yes && no               нет
  yes || no               да

Причина

Пара true и false нужна ради коротких && и || для своих типов. Компилятор собирает короткий && из трёх операторов: & считает результат, а true и false решают, нужно ли вообще вычислять правый операнд.

Сделали это для типов вроде SqlBoolean, где кроме да и нет есть третье значение — Null, то есть «неизвестно». Для такого значения оба оператора возвращают false: оно не проходит ни if (x), ни if (!x).

Где легко ошибиться

Объявить только true компилятор не разрешит: нужны оба оператора. При этом присвоить объект переменной типа bool или сравнить его с true по-прежнему нельзя — приведения к bool у типа нет.

Где встречается

В SqlBoolean: там объявлены оба оператора и оператор &, ровно как в примере. Это тип для колонки базы данных, где кроме да и нет бывает пустое значение.

5. Метод у пустой ссылки

Исходник

Есть утверждение, что метод класса вызовется без ошибки, если внутри он не обращается к полям: разыменовывать в таком методе нечего. Проверка на трёх случаях:

Sample empty = null;
 
empty.WithField();      // возвращает поле
empty.WithoutField();   // возвращает строку, к полям не обращается
empty.Extension();      // метод расширения

Что выводит отчёт

  ссылка пустая: True
 
  метод обращается к полю       NullReferenceException
  метод к полям не обращается   NullReferenceException
  метод расширения              выполнился, аргумент пустой

Причина

Компилятор C# на вызов метода у ссылочного типа выдаёт инструкцию callvirt даже для невиртуального метода — ради проверки на пустую ссылку. Обращение к полям тут ни при чём.

Метод расширения работает, потому что это не вызов на объекте: компилятор превращает его в статический вызов с аргументом. Внутри такого метода null приходит как значение параметра, и его можно проверить как любой другой аргумент.

Где легко ошибиться

В методе расширения проверка is null работает и нужна. В обычном методе она недостижима: до неё дело не дойдёт, исключение прилетит раньше.

Границы

Все прогоны на четырёх машинах сняты на Windows x64. Вывод с Linux в разделе про __arglist получен отдельно, на одной машине с Ubuntu 24.04, и подтверждён кодом джита.

Замена указателя на таблицу методов держится на том, что он записан в начале объекта. Microsoft этого нигде не обещала: реализацию могут изменить, и тогда приём перестанет работать. Сверка это заметит и остановит прогон.

__makeref, __reftype, __refvalue и __arglist в документации не описаны. Их могут убрать в любой версии компилятора без предупреждения — поэтому отчёты и запускаются на трёх рантаймах.

Код из статьи

UndocumentedProof — отчёты и выгрузки с четырёх машин

Ссылки

Всем удачи и до новых встреч!

А чё, так можно было? Недокументированный C#