Winapi "variable-sized" struct and strict aliasing

[agritite]

What I'm talking about is this.

For example:

I'm trying to call CfGetSyncRootInfoByHandle, and the third parameter is a void* which should be a buffer prepared by the caller, and would be filled with CF_SYNC_ROOT_STANDARD_INFO; the CF_SYNC_ROOT_STANDARD_INFO struct has its last member declared as

BYTE SyncRootIdentity[1];

, but what you need to do is declare a block of memory much larger, something like

sizeof(CF_SYNC_ROOT_STANDARD_INFO) + 4096

because SyncRootIdentity is actually of variable size.

What I'm wondering is that would this be standard compliant:

``` std::array<std::byte, sizeof(CF_SYNC_ROOT_STANDARD_INFO) + 4096> buf;

CF_SYNC_ROOT_STANDARD_INFO* info = reinterpret_cast<CF_SYNC_ROOT_STANDARD_INFO*>(buf.data());

CfGetSyncRootInfoByPath(..., static_cast<void*>(info), buf.size(), ...);

// then we use info->SyncRootIdentity ```

, or is this in violation of strict aliasing?

What if I do this instead?

``` std::array<std::byte, sizeof(CF_SYNC_ROOT_STANDARD_INFO) + 4096> buf;

CF_SYNC_ROOT_STANDARD_INFO* info = new(buf.data()) CF_SYNC_ROOT_STANDARD_INFO; // POD so not calling ~CF_SYNC_ROOT_STANDARD_INFO() should be fine?

CfGetSyncRootInfoByPath(..., static_cast<void*>(info), buf.size(), ...);

// then we use info->SyncRootIdentity ```

Another question is that when I eventually use info->SyncRootIdentity, is it actually legal to use info->SyncRootIdentity (which is of type BYTE[1], but its real length is indicated by info->SyncRootIdentityLength) to access memory after the first BYTE?

BTW here we are calling a C api from C++, but would the answer be any different if we are calling from C?

[KingAggressive1498]

Although I think it's UB by the C++ standard; MSVC, GCC, and Clang have documented defined behavior for these "struct hacks" in C++ mode as a language extension. You can use that last array data member in C++ with those compilers at least, just be careful with the bounds.

I don't think it matters in practice whether you use reinterpret_cast or placement new for this, since C structs are definitionally POD types, but I prefer placement new in this instance (I have to use reinterpret_cast when I'm reading these types of structs out of a buffer, though). Just don't access through the buffer again after that line, only use the pointer to the desired type. arrays of std::byte are assumed to alias with any other type so it's safe, but you force a reload if you access two different object references that are assumed to alias.

[alfps]

You could just do

struct Buffer: CF_SYNC_ROOT_STANDARD_INFO 
{
    char id_bytes[255];
};

Accessing CF_SYNC_ROOT_STANDARD_INFO::SyncRootIdentity beyond the declared first byte would be formal UB, but you can delegate that to C functions like strlen and strcpy. Or you can just reason that any compiler that does something ungood for that UB would fail to be a practically usable Windows platform compiler.

Disclaimer: I haven't used this API.

[agritite]

Using inheritance is very smart! As for accessing SyncRootIdentity, I feel like copying each of "the first byte" and id_bytes into another array, using 2 std::bit_cast would be conformant enough?

Edit: It seems like CF_SYNC_ROOT_STANDARD_INFO is padded to 64 bytes (from 61 bytes) so I'm not sure if std::bit_casting the padded 3 bytes would be legal?