On Mar 18, 2008, at 2:54 PM, Brian Aker wrote:
Hi!
So I have not looked at the code yet concerning this bit.... Is the
code safe from byte alignment problems between different endian
hosts/clients?
I am not sure that I understand your question, but the uint64_t is
transferred in network byte order..
the problematic code looks somewhat like (i don't have the source here
right now):
uint64_t *cas = packet + headersize + 4;
*cas = swap64(item->cas_id);
This section could be rewritten to:
uint64_t cas = swap64(item->cas_id);
memcpy(packet + headersize + 4, &cas, 8)
But since both fields are mandatory and we are currently working on
finishing the first version of the binary protocol, I don't see why
not just swap the order of the flag and the cas....
Hope this answers your question..
Trond
Cheers,
-Brian
On Mar 18, 2008, at 4:59 AM, Trond Norbye wrote:
Hi,
I have been testing the binary protocol the last few days and I
would like to suggest that we swap the order some fields to solve
some alignment problems.
The cas-id is a 64-bit datatype and will require 8-byte alignment
on some hardware, but it is placed on a 4-byte alignment in the get
response. The current get-response contains a 16 byte header
followed by the 4 byte flags-field causing the wrong alignment for
the cas id. If we swap the order on the two fields the cas-id will
get proper alignment, and we can access the field directly as an
uint64_t...
To be consistent I suggest that we move the cas-id to the front in
the set/add/replace command as well. The attached patch implements
this.
Trond
<alignment.patch.gz>
--
_______________________________________________________
Brian "Krow" Aker, brian at tangent.org
Seattle, Washington
http://krow.net/ <-- Me
http://tangent.org/ <-- Software
_______________________________________________________
You can't grep a dead tree.
