Byte order bug in token.c:send_deflated_token ?

Jay Fenlason fenlason at redhat.com
Mon Jan 5 21:49:27 GMT 2004


I was looking at send_deflated_token() when I noticed that it does

 int n, r;
...
 write_batch_delta_file((char *)&n,sizeof(char));
 temp_byte = (char)(n >> 8);
 write_batch_delta_file(&temp_byte,sizeof(temp_byte));

Now on a little-endian machine &n will equal the address of the
low-order byte of n, but on a big-endian machine, it'll equal the
address of the high-order byte.  It looks like the upshot of this is
that a batch delta file will be corrupted on a non-little-endian
machine.  I think what it should do is

 temp_byte = (char)(n&0xFF);
 write_batch_delta_file(&temp_byte,sizeof(char));
 temp_byte = (char)(n >> 8);
 write_batch_delta_file(&temp_byte,sizeof(temp_byte));

But I don't understand the code quite well enough.  Can someone who
knows the code tell me how off base I am?

Hmm.  I wonder what happen if n is > 65535 ?  I can't tell if that can
actually happen or not.

			-- JF


More information about the rsync mailing list