Anonymous nested unions: should they be marked?

[timsneath]

Take a struct like BLUETOOTH_ADDRESS:

typedef struct _BLUETOOTH_ADDRESS {
    union {
        BTH_ADDR ullLong;       //  easier to compare again BLUETOOTH_NULL_ADDRESS
        BYTE    rgBytes[ 6 ];   //  easier to format when broken out
    };
} BLUETOOTH_ADDRESS_STRUCT;

This is converted in metadata to this (C# representation):

public struct BLUETOOTH_ADDRESS
{
	[StructLayout(LayoutKind.Explicit)]
	public struct _Anonymous_e__Union
	{
		[FieldOffset(0)]
		public ulong ullLong;

		[FieldOffset(0)]
		public byte[] rgBytes;
	}

	public _Anonymous_e__Union Anonymous;
}

I presume a name (Anonymous) is required in ECMA-335 metadata, but of course that means that by default a projection's code has to write something like:

final bluetoothAddress = radioInfo.ref.address.Anonymous.rgBytes;

By contrast, in a struct like CHAR_INFO, the union is intended to be explicitly declared, yet there's no metadata difference between these two structs.

Is there a way we can mark anonymous nested unions like this so that the projection code knows that the Anonymous is really a non-identifier? What do other projections do here?

[mikebattista]

@sotteson1 @kennykerr @AArnott @marler8997 for their thoughts.

[AArnott]

I would like to see this as well. I think the anonymous union structs are used because the C parser we're using can guarantee that such generated types match the ABI when constructed this way, but it certainly doesn't yield a good API in C# (or other languages). If we can attribute them (or guarantee a naming convention) such that projections know it's safe to remove them, CsWin32 could do something nicer here as well. We might leave the struct there to avoid corrupting the ABI but add property accessors at the higher level that match the field names so that the fields are discovered at the same level that C would have.

[kennykerr]

In cases like this where there is only a single field and that single field is an anonymous union I think it would be safe to unroll it such that the surrounding type has the layout of the anonymous union. So this:

struct TYPE {
    union {
        bool a;
        int b;
    };
};

Becomes this:

union TYPE {
    bool a;
    int b;
};

In Rust, the former requires type.Anonymous.b = 123 while the latter would allow the simpler type.b = 123.

[timsneath]

Yeah, that would be nice. I think this is a relatively edge case, though. Perhaps a more representative example would be INPUT, or worse still, DECIMAL.

[kennykerr]

Yep, I don't have a good idea for how to improve those.

[marler8997]

This unrolling seams reasonable to me. I am wondering why the API defines structs that have a single union member, when defining it as a union would have the same affect. Anyone know why it was done this way in the first place?

[AArnott]

I think it was to make the C parser we're using's job easy by making every field offset 0 wherever a field offset has to be specified.
In the simple case of one field it probably makes no difference, but in the more complex cases, these anonymous structs appear in the middle of a bunch of fields and as a struct, the field offsets can be 0 but without it, the fields in the parent struct would have to be non-zero.

[mikebattista]

Duplicate of #99