How can access the lower half of a 64bit integer using C or C++? I can do it easily in Assembly but I have no clue on how to do it in C/C++
EDIT: What about accessing the upper half?
+8
A:
long long BigOne = 0x1234567890ABCDEFLL;
long long LowerHalf = BigOne & 0xFFFFFFFFLL;
long long UpperHalf = (BigOne >> 32) & 0xFFFFFFFFLL;
Sorry if the hexadecimal literals require some prefix/suffix, I'm not very familiar with C. Please fix the answer if you know.
Vilx-
2010-07-18 19:05:35
IVlad
2010-07-18 19:07:11
Okay, I understand it :)
kotarou3
2010-07-18 19:07:28
+1 for taking care of sign extension in UpperHalf
George
2010-07-18 19:07:53
Note that whether the right shift performs sign extension is implementation defined and thus not portable. It's usually best to avoid shifting signed values, where possible (it is rarely necessary to shift signed values in practice anyway). As for the suffix question: no suffix is necessary; the hexadecimal literal will be represented by an unsigned type if it cannot be represented by the signed type of the same size (if you used decimal literals, you would need a `u` suffix for "unsigned").
James McNellis
2010-07-18 19:10:13
Oh, so it's called "sign extension"? I didn't know what it was. :) I just know that sometimes it duplicates the first bit when right-shifting, so this takes care of that.
Vilx-
2010-07-18 19:13:34
A:
I have used all kinds of tricks to do this before. Using unions, long shifts ect..
Nowadays I just use memcopy. It may sound inefficient, but last time I checked the compiler optimized the code quite nice:
int32_t higher32 (unsigned long long arg)
{
unsigned char * data = (unsigned char *) arg;
int32_t result;
memcpy (&result, data+4, sizeof (int32_t));
return result;
}
int32_t lower32 (unsigned long long arg)
{
unsigned char * data = (unsigned char *) arg;
int32_t result;
memcpy (&result, data+0, sizeof (int32_t));
return result;
}
Nils Pipenbrinck
2010-07-18 19:34:27
-1 for ugly endian-dependent code when there's a trivial, fast way to do the right thing with arithmetic.
R..
2010-07-19 08:20:28