__int64 weirdness....

[John E]

Suppose you have a function that requires a long pointer to a DWORD - e.g.

void SomeFunc (LPDWORD data)
{
. . .
}

Now suppose you call it with the address of WORD - e.g.

WORD myData = 210;
SomeFunc (&myData);

The above produces a compiler warning and SomeFunc(...) receives corrupted data. You can overcome this using a cast - e.g.

WORD myData = 210;
SomeFunc ((LPDWORD)&myData);

Here's my question. WORD is an unsigned int, DWORD is an unsigned 32 bit int - so why doesn't this work for an unsigned 64 bit int - e.g.

void SomeFunc (unsigned __int64 *data)
{
. . .
}

DWORD myData = 210;
SomeFunc ((unsigned __int64 *)&myData);

In the above example, SomeFunc(...) still receives corrupted data. Why

[Codeplug]

WORD = unsigned short = 2 bytes
DWORD = unsigned int = 4 bytes
usigned __int64 = 8 bytes

When you dereference a pointer to an __int64, it expects 8 bytes of valid data, not 2, and not 4.

gg

[John E]

Ooer.... I just realised that it doesn't work with the WORD/DWORD example either. It just looked like it was working...!

[Gorgor]

I haven't done any 64 bit programming, yet. Do int64's have to be 8-byte aligned, the way 32 bit ints have to be 4-byte aligned?

If so, that might be another cause of the problem. &some32BitVar might only be 4-byte aligned and not 8, and hence would generate a processor exception when executed.

If this is NOT necessary, then, at best, you would try to interpret 4 "garbage" bytes as part of the 8 byte integer.