Why is struct DROPFILES packed(1)?

[knopp]

This causes warning (borrow of packed field is unsafe and requires unsafe function or block (error E0133)) when accessing fields.

[tim-weis]

This has me confused, too. First, the technical reason is that the ShlObj_core.h SDK header file has an

#include <pshpack1.h>

directive right at the top, so the packing winds up in the metadata, and re-surfaces in the generated code. In the specific case of DROPFILES it appears, that packed(1) doesn't change the layout, at least for Intel's x86 and x86_64 architectures. I'm not sure this holds for all architectures, though I believe it is required by Windows' ABI.

It would certainly be nice to have a more versatile structure definition, in case the stronger packing requirement doesn't change the structure layout. The code generator could omit the packing attribute, if it can determine, that it is superfluous. The Layout type seems to provide all the required building blocks to determine this.

Except, there's more to structure packing than packing: packed(1) also implies align(1) (as hinted to under Type Layout, although there is quite some confusion on that topic, and the lack of a formal specification doesn't help much). While the code generator can verify that a packed structure has the same layout as its non-packed variant, it cannot retroactively enforce stricter alignment.

I suppose the only safe option here is to follow C, which relaxes the alignment requirements for packed structures on all 3 major C++ compilers. A corollary of this is that you cannot have references into a packed structure without exhibiting undefined behavior. This tracking issue illustrates workarounds.

[kennykerr]

Right, the packing comes from metadata. If you can make a case for the packing not affecting the struct's layout you can create an issue here to request this be dropped:

https://github.com/microsoft/win32metadata

[kennykerr]

I also created an issue to improve trait coverage for such types. #656