Re: [lwip-devel] Bug in Checksum implementation and ARP fix

[Kenneth Porter]

--On Thursday, October 23, 2003 9:47 AM +0100 Kieran Mansley <address@hidden>
wrote:

> I think I'm starting to see what you're getting at.  However, as this
> seems to be an isolated case (we're not getting reports of other casts
> breaking some architectures) and the long term plan is to make the
> checksum routines architecture specific, it should be sufficient for the
> time being to fix the existing checksum function and remind developers to
> be careful when casting.

Makes sense, but I would point out why I'm sensitized to this: I ported some
code from an 8-bit architecture to a 32-bit DSP a couple years ago, and the
most troublesome part of the port was the assumption that casting to a char
performed masking to 8 bits. The DSP's word size was a fixed 32 bits (ie. you
couldn't address anything less than that) so the compiler defined chars,
shorts, and longs as 32 bits, and casting to char was a no-op. My solution was
to change all such casts to the macro MASK_TO_8_BITS(x) and then define that
macro as appropriate for each architecture (cast in the original case, the
most efficient idiom for that compiler, and "((x) & 0xFF)" for the DSP).

Now it's conceivable that someone might want to port lwip to such an
architecture, so those coding casts to convert word sizes should consider that
not all architectures have varying sizes for char/short/long. Nor that the
packet buffer is defined in 8-bit units.

So make your assumptions about word sizes (and buffer packing) explicit,
either by using macros for conversions, or by heavy use of comments.