Skip to content

Incorrect struct padding when using CRepr #2477

Description

@ESFraser

I have discovered an issue with CRepr structs in beef. The size of Foo appears to be calculated differently in some cases? alignof(Foo) shows 16 as expected, and strideof(Foo) shows 64 as expected. However, writing to the value testArray[1] will write to the struct without the extra 8 bytes of padding.

I have attached a simple repro program class that should replicate the issue, as well as comments to explain the expected and observed behaviours. I have tested this on Nightly 07/18/2026.

Further testing appears to indicate that the issue is somehow related to the Align(16) on the Vector3 type, as removing that seems to resolve the issue? However that alignment is required in our codebase as we use Vector3 for SIMD operations, so removing it isn't an option for us.

class Program
{
    [CRepr, Align(16)]
	public struct Vector3
	{
		public float x;
		public float y;
		public float z;
		float padding;
	}

	[CRepr]
	public struct Foo
	{
		public Vector3[2] positions;
		public float size;
		public uint32 id;
		public uint32 flags;
		public bool condition;

		public Object objReference;
		// float[2] padding; // Padding needs to be manually added here or for alignment to match
	}

	public static int Main(String[] args)
	{
		Foo[2] testArray = .();

		// Observe that the values are written to the expected location: positions[0].x = 1, positions[0].y = 2, positions[0].z = 3
		testArray[0].positions[0].x = 1;
		testArray[0].positions[0].y = 2;
		testArray[0].positions[0].z = 3;

		// Observe that the values are written 8 bytes ahead of what they should be: positions[0].x = 0, positions[0].y = 0, positions[0].z = 1, positions[0].padding = 2, etc.
		testArray[1].positions[0].x = 1;
		testArray[1].positions[0].y = 2;
		testArray[1].positions[0].z = 3;

		return 0;
	}
}

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions