-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
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
LARGE_INTEGER/ULARGE_INTEGER should map to Int64/UInt64 #69
Comments
This comment has been minimized.
This comment has been minimized.
So it is indeed safe to replace |
I believe that doing this would break ABI, based on my experiences with microsoft/cppwin32#3. The gist of what I found in that defect is that this: int64 f1(); and this: struct S
{
int 64 value;
}
S f2(); are going to push different amounts of stuff onto the stack, causing memory corruption and crashes if we try to pretend one of them is the other. We need to keep these structs as-is in the metadata. Projections are free to simplify them and project them idiomatically, but the structs need to exist in metadata so that we preserve ABI compatibility. |
Right, there is a peculiarity in the C++ ABI for the Visual C++ compiler that results in these being different when If your language doesn't yet map this in a natural way, I suggest you open an issue with the language team. |
Okay just so we're on the same page - should I open an issue on CsWin32 to have the struct projected to int64/uint64? |
Yes, for C# it would be the CsWin32 repo. |
@saul - I've just transferred it here for you. |
These structs date back to a time where C compilers didn't natively support 64-bit integers. I think these should be represented as System.Int64 and System.UInt64 in the metadata.
I tried having a go at this myself by adding:
To
generation/baseRemap.rsp
, but to my surprise it just resulted in Microsoft.Windows.Sdk.Int64 and Microsoft.Windows.Sdk.UInt64 types being generated.Do you think this is a reasonable change?
The text was updated successfully, but these errors were encountered: