William "Chops" Westfield wrote:

>> Good catch. Your solution would be a possibility, and IMO is still
>> preferred over the use of comments instead of names in code, but it's
>> also just as easy to combine both methods and write 
>> 
>> frame.destinationMac[] = { 0x00,0x03,0x6f,0x23,0x25,0x4a };
> 
> I rather liked his packet layout and accompanying comments.

It was organized. What I don't like is that in every place where you want
to access the packet contents, you have to count bytes and hope that you
get the right index. Since it's not possible to intersperse #define (or
const int definitions) with the packet array definition, it's not possible
either to have them next to the appropriate comment. 

Using a struct of char arrays, with their sizes defined as #define (or
const int, depending on the target compilers) is IMO much clearer to use.

> Don't forget that C is allowed to insert arbitrary padding into
> structures; mapping (on-wire) packets directly to structures can be
> fraught with peril (fortunately, there is usually a mechanism to allow
> it to be done.  

Yes. I haven't had a problem with char arrays in struct being padded.

> Not counting endianness.  

If you want to write really portable network code, you just have to have a
mechanism to deal with endianness, and this isn't that complex once you
have it in place. So in this case this isn't any extra hit either. (OTOH,
using char arrays in structs avoids endian problems the same way the
original code avoided them.)

> And occasional bitfields that span a byte boundry in ways that particular
> compilers can't deal with...)  

Right... it's not easy (probably impossible) to write 100% portable code
(in the sense that you can run it on any C compiler on the planet). So you
have to make some assumptions... either you write ANSI code and read
compiler and platform docs for every target or you read compiler and
platform docs for every target :)

> The byte array makes things clear and obvious from a "what it actually
> looks like" point of view, and the comments (as long as they stay
> accurate) explain things at the protocol level.

Yes, I see that. But think of the code accessing the array... for example
extracting the source IP. Try to picture you reviewing that code, with all
those magic numbers in the code:

  uchar *sourceIp = frame + 27; // Let's all pray we counted right :)

I prefer to be able to use frame.sourceIp wherever I need the source IP.
Especially since it doesn't cost extra to write and nothing at runtime
either.

Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist