Various enums have the incorrect underlying type making certain functions un-linkable and un-callable

[kennykerr]

__imp__AcceptSecurityContext@40 __imp__AcceptSecurityContext@36
__imp__InitializeSecurityContextA@52 __imp__InitializeSecurityContextA@48
__imp__InitializeSecurityContextW@52 __imp__InitializeSecurityContextW@48
__imp__SaslAcceptSecurityContext@40 __imp__SaslAcceptSecurityContext@36
__imp__SaslInitializeSecurityContextA@52 __imp__SaslInitializeSecurityContextA@48
__imp__SaslInitializeSecurityContextW@52 __imp__SaslInitializeSecurityContextW@48

These all looks like win32metadata bugs where the signatures are improperly declared, mixing 32 bit and 64 bit integer types. For example, the win32metadata uses enums like ASC_REQ_FLAGS instead of unsigned 32 bit parameters but the enum's underlying type is an unsigned 64 bit integer. Same for ISC_REQ_FLAGS. This then throws off the stdcall stack size calculation and of course makes these functions uncallable.

I wish the win32metadata could just validate this against the lib files in the SDK using dumpbin.

I'll create a win32metadata issue for this.

Originally posted by @kennykerr in microsoft/windows-rs#1999 (comment)

[elachlan]

Similar issue in #1213. It has a counter case of a field being moved from uint to byte because the enum values are byte sized. Would this change fail the suggested validation?

[kennykerr]

Yes.

[kennykerr]

If nothing else, we should have a test here that validates that the transformation to enum didn't change the size of any parameters in the process.

[sotteson1]

I have code that is supposed to be checking for this, but there was a problem that was keeping it from working on parameters (was working only for fields).

[riverar]

Suspect this is also related to

• MINIDUMP_CALLBACK_INPUT packing/alignment problem #460 (comment)
• Packing Size #870 (comment)