LARGE_INTEGER/ULARGE_INTEGER should map to Int64/UInt64 about cswin32 HOT 7 CLOSED

FILETIME and ULARGE_INTEGER are not interchangeable because they have different alignment. FILETIME consists of two 32-bit fields whereas ULARGE_INTEGER consists of a union, one of whose fields is a single 64-bit value. Hence the alignment of ULARGE_INTEGER will be 8 bytes and the alignment of FILETIME will be 4 bytes.

So it is indeed safe to replace ULARGE_INTEGER and LARGE_INTEGER with uint64 and int64 but it is not safe to do so for FILETIME.

from cswin32.

Yes, for C# it would be the CsWin32 repo.

from cswin32.

@saul - I've just transferred it here for you.

from cswin32.

There are other types like FILETIME with the same layout as ULARGE_INTEGER, where Microsoft recommends not to replace the structure with a 64 bit integer because of alignment issues. I neither am sure if this also applies for LARGE_INTEGER and ULARGE_INTEGER, nor if this even affects modern CPUs that Windows runs on.

from cswin32.

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.

from cswin32.

Right, there is a peculiarity in the C++ ABI for the Visual C++ compiler that results in these being different when stdcall is involved. Rust for Windows already maps these to i64 and u64 because it doesn't suffer from this weirdness, but Visual C++ may not be able to handle that reliably.

If your language doesn't yet map this in a natural way, I suggest you open an issue with the language team.

from cswin32.

Okay just so we're on the same page - should I open an issue on CsWin32 to have the struct projected to int64/uint64?

from cswin32.