UpdateProcThreadAttribute should use u32 for 'attribute' argument

[zaddach]

The argument attribute to UpdateProcThreadAttribute is a usize, even though the attributes (such as PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES are u32.

[mikebattista]

I'm not sure how to handle this one.

The API is defined as accepting a DWORD_PTR so the function definition in the metadata is true to the headers.

The constants are defined in https://github.com/microsoft/win32metadata/blob/main/generation/WinSDK/Partitions/Threading/main.cpp if someone can recommend how they should be changed to align with the API.

[riverar]

There's a mismatch but I don't think we can do much here, due to ABI compatibility constraints.

[ChrisDenton]

Are PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES used anywhere else? If not then I guess it could be expanded to being pointer-sized?

More generally there are places where the same constants are used for different sized types. Which doesn't play well with strong typing, so there's not really a solution in the general case.

[riverar]

I think we had a similar discussion in #1502 (comment) where we discussed how various structures, enumerations, etc. may be used in third party code (e.g. libs) and seemingly innocuous deviations from the definitions may cause unintended side effects. (There were some godbolt examples in there demonstrating some optimizer shortcuts that would fail.)

[ChrisDenton]

I absolutely agree we shouldn't be changing the ABI. Both of functions and structs. I'm less clear on integer widths of #defines though. They're already a bit weird (preprocessor magic) and when combined with C/C++'s integer promotion rules I'm not sure how meaningful the size is on its own. I mean, purely in terms of bitwidth. Signed/unsigned might be a bit more meaningful.

[mikebattista]

Closing for now. Reactivate if there's something actionable here.