LayoutKind.Sequential не используется, если подструктура имеет LayoutKind.Explicit

При запуске этого кода:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;

namespace StructLayoutTest
{
    class Program
    {
        unsafe static void Main()
        {
            Console.WriteLine(IntPtr.Size);
            Console.WriteLine();


            Sequential s = new Sequential();
            s.A = 2;
            s.B = 3;
            s.Bool = true;
            s.Long = 6;
            s.C.Int32a = 4;
            s.C.Int32b = 5;

            int* ptr = (int*)&s;
            Console.WriteLine(ptr[0]);
            Console.WriteLine(ptr[1]);
            Console.WriteLine(ptr[2]);
            Console.WriteLine(ptr[3]);
            Console.WriteLine(ptr[4]);
            Console.WriteLine(ptr[5]);
            Console.WriteLine(ptr[6]);
            Console.WriteLine(ptr[7]);  //NB!


            Console.WriteLine("Press any key");
            Console.ReadKey();
        }

        [StructLayout(LayoutKind.Explicit)]
        struct Explicit
        {
            [FieldOffset(0)]
            public int Int32a;
            [FieldOffset(4)]
            public int Int32b;
        }

        [StructLayout(LayoutKind.Sequential, Pack = 4)]
        struct Sequential
        {
            public int A;
            public int B;
            public bool Bool;
            public long Long;
            public Explicit C;
        }
    }
}

Я ожидаю, что этот результат будет ОБА на x86 и x64:
4 или 8 (в зависимости от x86 или x64)

2
3
1
6
0
4
5
мусор

Что я получаю вместо этого на x86:
4

6
0
2
3
1
4
5
мусор

Что я получаю вместо этого на x64:
8

6
0
2
3
1
0
4
5

Дополнительно:
- Проблема исчезает, когда я удаляю атрибуты LayoutKind.Explicit и FieldOffset.
- Проблема исчезает, когда я удаляю поле Bool.
- Проблема исчезает, когда я удаляю длинное поле.
- Обратите внимание, что в x64 параметр атрибута Pack=4 тоже игнорируется?

Это относится к .Net3.5, а также к .Net4.0.

Мой вопрос: что я упускаю? Или это ошибка?
Я нашел похожий вопрос:
Почему LayoutKind.Sequential работает по-разному, если структура содержит поле DateTime?
Но в моем случае макет меняется, даже когда атрибут подструктуры изменения, без каких-либо изменений в типах данных. Так что на оптимизацию не похоже. Кроме того, я хотел бы отметить, что еще один вопрос остается без ответа.
В этом другом вопросе они упоминают, что макет соблюдается при использовании Marshalling. Я не проверял это сам, но мне интересно, почему макет не соблюдается для небезопасного кода, поскольку все соответствующие атрибуты, кажется, на месте? Упоминается ли где-нибудь в документации, что эти атрибуты игнорируются, если не выполняется сортировка? Почему?
Учитывая это, могу ли я вообще ожидать, что LayoutKind.Explicit будет надежно работать с небезопасным кодом?
Более того, в документации упоминается мотив сохранения структур с ожидаемым макетом:

Чтобы уменьшить проблемы, связанные с макетом, связанные со значением Auto, компиляторы C#, Visual Basic и C++ задают макет Sequential для типов значений.


Но этот мотив видимо не относится к небезопасному коду?


.net c# unsafe structlayout layoutkind.explicit
person Roland Pihlakas    schedule 02.05.2013    source источник

Ответы (1)


arrow_upward
11
arrow_downward

Из статьи библиотеки MSDN для перечисления LayoutKind:

Точное положение каждого члена объекта в неуправляемой памяти явно контролируется в зависимости от настройки поля StructLayoutAttribute.Pack. Каждый член должен использовать атрибут FieldOffsetAttribute, чтобы указать положение этого поля в типе.

Соответствующая фраза выделена, в этой программе этого не происходит, указатель по-прежнему очень сильно разыменовывает управляемую память.

И да, то, что вы видите, идентично тому, что происходит, когда структура содержит элемент типа DateTime, к которому применен [StructLayout(LayoutKind.Auto)]. Код сортировщика полей в среде CLR, определяющий макет, старается учитывать LayoutKind.Sequential и для управляемых структур. Но он быстро и без визга сдастся, если встретит члена, противоречащего этой цели. Для этого достаточно структуры, которая сама по себе не является последовательной. Вы можете увидеть, как это делается в исходнике SSCLI20. , src/clr/vm/fieldmarshaler.cpp, найдите fDisqualifyFromManagedSequential

Это заставит его переключиться на автоматический макет, то же правило макета, которое применяется к классам. Он переупорядочивает поля, чтобы свести к минимуму отступы между членами. В результате требуется меньше памяти. После члена «Bool» есть 7 байтов заполнения, неиспользуемое пространство для выравнивания члена «Long» по адресу, кратному 8. Конечно, очень расточительно, это исправляет это, делая длинный первый член в макете .

Таким образом, вместо явного макета с аннотацией /* смещение - размер */:

        public int A;        /*  0 - 4 */
        public int B;        /*  4 - 4 */
        public bool Bool;    /*  8 - 1 */
        // padding           /*  9 - 7 */
        public long Long;    /* 16 - 8 */
        public Explicit C;   /* 24 - 8 */
                     /* Total:  32     */

Получается:

        public long Long;    /*  0 - 8 */
        public int A;        /*  8 - 4 */
        public int B;        /* 12 - 4 */
        public bool Bool;    /* 16 - 1 */
        // padding           /* 17 - 3 */
        public Explicit C;   /* 20 - 8 */
                     /* Total:  28     */

С легким 4 байта памяти сохранены. 64-битная компоновка требует дополнительного заполнения, чтобы гарантировать, что значение long по-прежнему выровнено при сохранении в массиве. Все это крайне недокументировано и может быть изменено, никогда не полагайтесь на управляемую структуру памяти. Только Marshal.StructureToPtr() может дать вам гарантию.

person Hans Passant    schedule 03.03.2014