Blittable interop with "fixed" arrays and pointers

[MichalStrehovsky]

I was doing interop with a C library that defines data structures along these lines:

typedef struct sg_subimage_content {
    const void* ptr;    /* pointer to subimage data */
    int size;           /* size in bytes of pointed-to subimage data */
} sg_subimage_content;

typedef struct sg_image_content {
    sg_subimage_content subimage[SG_CUBEFACE_NUM][SG_MAX_MIPMAPS];
} sg_image_content;

typedef struct sg_image_desc {
    // <Snip>
    sg_image_content content;
    // <Snip>
}

I wanted to define a blittable equivalent in C#.

The usual trick is to define sg_image_content as StructLayout(Explicit, Size = XXX) and make an indexer that exposes individual elements (similar to how the C# fixed array does it). But the problem is that the individual elements have pointers so the size depends on the architecture.

Failing that, one can just manually unroll the array into SG_CUBEFACE_NUM * SG_MAX_MIPMAPS fields. In my case, that came down to 96 fields.

Just wondering whether people have a feel for how common is this situation and whether we need better primitives to enable such scenarios. (E.g. being able to specify the size as two numbers that would be used as const1 + PTR_SIZE * const2).

[EgorBo]

Isn't it better to just wait for dotnet/csharplang#1314
so you will be able to define fixed sg_subimage_content subimage[SG_CUBEFACE_NUM * SG_MAX_MIPMAPS]; ?

[MichalStrehovsky]

Oh neat. Didn't realize C# is considering emitting the bag of fields with a sequential layout instead of the single explicit layout struct with an explicit size. Switching back and forth between Explicit and Sequential layout has impact on calling conventions though so this will have to be done carefully. But it would solve the scenario I hit, albeit with a size impact (all those fields are not free).

[jkotas]

We do not want to be emitting hundreds of dummy fields just to inflate the struct to the right size. The plan is to have runtime feature to solve that problem #12320

[MichalStrehovsky]

The plan is to have runtime feature to solve that problem #12320

Missed that. We can close as dupe of that then.