Annotate struct size fields in metadata

[DoctorKrolic]

It is common in windows API to have a "sizeof" field in a struct (usually called dwSize) for versioning. I believe metadata can introduce a new [SizeOf] attribute or similar and annotate such fields with it. Generators using metadata can then account for that attribute and automatically assign right value to the annotated field. For instance, CsWin32 can do that in a friendly function overload

[jevansaks]

This is a good suggestion. @riverar Would such a thing be useful in the Rust implementation too?

[riverar]

Sadly no. (I see this suggestion a lot.)

Automatic initialization like this wouldn't work universally. For example, Shell_NotifyIcon accepts multiple versions of NOTIFYICONDATA, which the API distinguishes using the cbSize field. An automatic initialization scheme would need to telepathically know which version the developer intended to use.

[jevansaks]

I wasn't thinking automatic initialization of cbsize, for that part I was thinking of just a generated method on the struct to initialize to the size of that struct.

But the general problem is for something like Shell_NotifyIconW where we don't know the struct is potentially variable-sized. But I'm now seeing that StructSizeFieldAttribute exists so that's the answer to @DoctorKrolic 's original question. We need to teach cswin32 about that attribute.

[riverar]

Automatic initialization of cbSize by a generator would require silent assumptions about the consuming developer's intent. The appropriate value depends on the target Windows version and required features (NOTIFYICONDATA_V1_SIZE, NOTIFYICONDATA_V2_SIZE, NOTIFYICONDATA_V3_SIZE, or sizeof(NOTIFYICONDATA)).

[DoctorKrolic]

For example, Shell_NotifyIcon accepts multiple versions of NOTIFYICONDATA, which the API distinguishes using the cbSize field. An automatic initialization scheme would need to telepathically know which version the developer intended to use.

As I see from docs, there are indeed 2 versions of that structure - one with szTip of 64 chars max and newer one with 128. Metadata defines szTip with 128 max chars therefore it always uses the later version, so developers don't really has a choice here. If they pass czSize as a size of previous version, the function will read the struct as it was that previous version, leading to inevitable data corruption. In order to use the previous version, the previous version of the structure with correct memory layout is required and AFAICT metadata does not define it. At least, this is how I undertand it. And on top of all that, the version split was in Windows 2000, so we can safely assume this isn't a problem for us (at last in this particular case). I am not sure whether rust supports such ancient version of Windows, but .NET definitely does not