Erik, I cannot answer your first question, but the bit manipulation in
second question is decoding of little endian.
You can do memcpy on Intel, but not on SPARC.
( on intel you can also use tmp = *(int64 *)ptr;
since alignment is not an issue here)
> -----Original Message-----
> From: Lars-Erik.Bjork@stripped [mailto:Lars-Erik.Bjork@stripped]
> Sent: Friday, December 19, 2008 11:40 AM
> To: falcon@stripped
> Subject: Some questions
>
> Hi again.
>
> There is some parts of StorageDatabase::getSegmentValue that confuses
> me.
>
> First of all, it seems that some of the keys are passed from the
> server as endian independent, whereas some of them are not. Do you
> know if that really is the case? It looks kind of strange to me.
>
> Second, why do we do things like this:
>
> int64 temp = (int64)
> ((uint64)(((uint32) ((UCHAR) ptr[0])) +
> (((uint32) ((UCHAR) ptr[1])) << 8) +
> (((uint32) ((UCHAR) ptr[2])) << 16) +
> (((uint32) ((UCHAR) ptr[3])) << 24)) +
> (((uint64)(((uint32) ((UCHAR) ptr[4])) +
> (((uint32) ((UCHAR) ptr[5])) << 8) +
> (((uint32) ((UCHAR) ptr[6])) << 16) +
> (((uint32) ((UCHAR) ptr[7])) << 24)))
> << 32));
> value->setValue(temp);
>
> instead of
>
> int64 temp;
> memcpy(&temp, ptr, sizeof(temp));
> value->setValue(temp);
> ?
>
> Is the memcpy significantly slower? It is used elsewhere in the same
> method, for example for float. I find the memcpy alternative to be
> much more readable, that is for sure!
> Maybe I am just mixing things here, I used to be a Java boy, all this
> casting and bit-shifting confuses me :)
>
> /Lars-Erik
>
> --
> Falcon Storage Engine Mailing List
> For list archives: http://lists.mysql.com/falcon
> To unsubscribe: http://lists.mysql.com/falcon?unsub=1
