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

[Kenneth Porter]

--On Wednesday, October 22, 2003 9:21 AM +0100 Kieran Mansley 
<address@hidden> wrote:

> Would this mean we'd need a macro for every combination of from-type and
> to-type?  If so, there could be a very large number of them,

I'd hope there weren't a lot of casts littering the code, with all kinds of 
types. Casts should be used in exceptional situations, not the norm.

> and the
> macros would be effectively hiding the cast making it harder to see what
> was going on.  Someone coming along, reading the code, and seeing
> "hbb2hs(var)" is not going to have a clue what it means, whereas
> "(u16_t *)var" gives a lot more information.
>
> I'd vote for keeping the casts out in the open, but I feel like I must be
> missing something as I still don't really see the problem.

This is similar to suggesting that we should code in assembly language, 
because C obscures what's "really" going on behind the scenes.

The objective is not to obscure, but to abstract. The macro (or in some 
cases, function) would be abstracting the operation of parsing a raw byte 
stream into larger objects that may require alignment for some 
architectures. The purpose is exactly that of the h2n macros used to 
convert endianness, handling architectural details and maintaining 
portability of the code, as well as allowing efficiencies on some 
architectures.

Remember that the cast is an implementation detail, not an algorithm. It's 
sufficient for some architectures but not all. Extracting shorts and longs 
from byte buffers is common enough in low-level network code to use macros 
defined within architecture conditionals that use the most efficient idiom 
that's correct for that architecture.