We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Int64
IntPtr
Discrepancies where the numbers are different
Looks like these are also win32metadata bugs. For example CfDisconnectSyncRoot is defined as follows in metadata:
CfDisconnectSyncRoot
public struct CF_CONNECTION_KEY { public IntPtr Value; } public static extern HRESULT CfDisconnectSyncRoot([In] CF_CONNECTION_KEY ConnectionKey);
That explains why windows-rs says the stack size is 4 since IntPtr is 4 bytes on x86.
windows-rs
But that's not accurate since the definition of CF_CONNECTION_KEY in the Windows SDK is always 8 bytes, regardless of architecture:
CF_CONNECTION_KEY
#define DECLARE_OPAQUE_KEY( name ) \ typedef struct name##__ { \ LONGLONG Internal; \ } name, *P##name DECLARE_OPAQUE_KEY( CF_CONNECTION_KEY );
LONGLONG is just a typedef for __int64.
LONGLONG
__int64
Originally posted by @kennykerr in microsoft/windows-rs#1985 (comment)
The text was updated successfully, but these errors were encountered:
Not yet fixed #871
Sorry, something went wrong.
Eek - we really should get this fixed.
Duplicate of #871
No branches or pull requests
Looks like these are also win32metadata bugs. For example
CfDisconnectSyncRoot
is defined as follows in metadata:That explains why
windows-rs
says the stack size is 4 sinceIntPtr
is 4 bytes on x86.But that's not accurate since the definition of
CF_CONNECTION_KEY
in the Windows SDK is always 8 bytes, regardless of architecture:LONGLONG
is just a typedef for__int64
.Originally posted by @kennykerr in microsoft/windows-rs#1985 (comment)
The text was updated successfully, but these errors were encountered: