[BusyBox] udhcp patches/ endianess

[Rainer Weikusat]

Eric Lammerts <busybox at lists.lammerts.org> writes:
> On Mon, 31 Jan 2005, Rainer Weikusat wrote:
>> Compile-time support for different endianesses.
>
>> +choice
>> +	prompt "Target byte order"
>
> No need for a new config option...
>
> #include <endian.h>
> #if __BYTE_ORDER == __LITTLE_ENDIAN
>
> But you shouldn't those defines anyway.

I think I should ;-). I cannot see the point in using code at run time
to determine facts known at compile time that never change.

> Your stuff looks terribly complicated, why not do something simple
> like this?

It's cheaper (needs only half of the iterations of the 16 bit version
and - more important - only half of the memory acesses). 

> --- networking/udhcp/packet.c.orig	2005-02-01 09:04:03.000000000 -0500
> +++ networking/udhcp/packet.c	2005-02-01 09:05:21.000000000 -0500
> @@ -93,17 +93,14 @@
>
>  	while (count > 1)  {
>  		/*  This is the inner loop */
> -		sum += *source++;
> +		sum += ntohs(*source);
> +		source++;

Eh ... first, this is the original algorithm, not the version that has
been modified by me. Due to the fact that the sum is
endian-independant (cf the relevant RFCs), it's pointless to swap the
bytes here.

>  		count -= 2;
>  	}
>
>  	/*  Add left-over byte, if any */
>  	if (count > 0) {
> -		/* Make sure that the left-over byte is added correctly both
> -		 * with little and big endian hosts */
> -		uint16_t tmp = 0;
> -		*(uint8_t *) (&tmp) = * (uint8_t *) source;
> -		sum += tmp;
> +		sum += *(uint8_t *)source << 8;

And this would additionally be broken, because it will calculate the
wrong sum for little endian machines (that's what the original trick
avoids by writing the left over octet into the 'lower' [address-wise]
portion of tmp, which will, depending on the endianess of the machine
the code is running on, cause it to become MSB or LSB, whatever is
'correct').