rsync - Jan 2004 - Byte order bug in token.c:send_deflated_token ?

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

On Mon, Jan 05, 2004 at 04:49:27PM -0500, Jay Fenlason
wrote:
> I think what it should do is
>  temp_byte = (char)(n&0xFF);
>  write_batch_delta_file(&temp_byte,sizeof(char));
Yes, the other code was wrong.  I've checked in a fix to CVS.  Thanks
for pointing this out.

..wayne..