Why does LayoutKind.Sequential work differently if a struct contains a DateTime field?
Consider the following code (a console app which must be compiled with "unsafe" enabled):
using System;
using System.Runtime.InteropServices;
namespace ConsoleApplication3
{
static class Program
{
static void Main()
{
Inner test = new Inner();
unsafe
{
Console.WriteLine("Address of struct = " + ((int)&test).ToString("X"));
Console.WriteLine("Address of First = " + ((int)&test.First).ToString("X"));
Console.WriteLine("Address of NotFirst = " + ((int)&test.NotFirst).ToString("X"));
}
}
}
[StructLayout(LayoutKind.Sequential)]
public struct Inner
{
public byte First;
public double NotFirst;
public DateTime WTF;
}
}
Now if I run the code above, I get output similar to the following:
Address of struct = 40F2CC
Address of First = 40F2D4
Address of NotFirst = 40F2CC
Note that the address of First is NOT the same as the address of the struct; however, the address of NotFirst is the same as the address of the struct.
Now comment out the "DateTime WTF" field in the struct, and run it again. This time, I get output similar to this:
Address of struct = 15F2E0
Address of First = 15F2E0
Address of NotFirst = 15F2E8
Now "First" does have the same address as the struct.
I find this behaviour surprising given the use of LayoutKind.Sequential. Can anyone provide an explanation? Does this behaviour have any ramifications when doing interop with C/C++ structs that use the Com DATETIME type?
[EDIT] NOTE: I have verified that when you use Marshal.StructureToPtr() to marshal the struct, the data is marshalled in the correct order, with the "First" field being first. This seems to suggest that it will work fine with interop. The mystery is why the internal layout changes - but of course, the internal layout is never specified, so the compiler can do what it likes.
[EDIT2] Removed "unsafe" from struct declaration (it was leftover from some testing I was doing).
[EDIT3] The original source for this question was from the MSDN C# forums:
Why does LayoutKind.Sequential work differently if a struct contains a DateTime field?
It is related to the (surprising) fact that DateTime
itself has layout "Auto" (link to SO question by myself). This code reproduces the behavior you saw:
static class Program
{
static unsafe void Main()
{
Console.WriteLine("64-bit: {0}", Environment.Is64BitProcess);
Console.WriteLine("Layout of OneField: {0}", typeof(OneField).StructLayoutAttribute.Value);
Console.WriteLine("Layout of Composite: {0}", typeof(Composite).StructLayoutAttribute.Value);
Console.WriteLine("Size of Composite: {0}", sizeof(Composite));
var local = default(Composite);
Console.WriteLine("L: {0:X}", (long)(&(local.L)));
Console.WriteLine("M: {0:X}", (long)(&(local.M)));
Console.WriteLine("N: {0:X}", (long)(&(local.N)));
}
}
[StructLayout(LayoutKind.Auto)] // also try removing this attribute
struct OneField
{
public long X;
}
struct Composite // has layout Sequential
{
public byte L;
public double M;
public OneField N;
}
Sample output:
64-bit: True Layout of OneField: Auto Layout of Composite: Sequential Size of Composite: 24 L: 48F050 M: 48F048 N: 48F058
If we remove the attribute from OneField
, things behave as expected. Example:
64-bit: True Layout of OneField: Sequential Layout of Composite: Sequential Size of Composite: 24 L: 48F048 M: 48F050 N: 48F058
These example are with x64 platform compilation (so the size 24, three times eight, is unsurprising), but also with x86 we see the same "disordered" pointer addresses.
So I guess I can conclude that the layout of OneField
(resp. DateTime
in your example) has influence on the layout of the struct containing a OneField
member even if that composite struct itself has layout Sequential
. I am not sure if this is problematic (or even required).
According to comment by Hans Passant in the other thread, it no longer makes an attempt to keep it sequential when one of the members is an Auto
layout struct.