On Fri, March 14, 2014 10:07 pm, Martin Townsend wrote:
> See below
[…]
>> +struct ieee802154_hdr_fc {
>> +#if defined(__LITTLE_ENDIAN_BITFIELD)
>> + u16 type:3,
>> + security_enabled:1,
>> + frame_pending:1,
>> + ack_request:1,
>> + intra_pan:1,
>> + reserved:3,
>> + dest_addr_mode:2,
>> + version:2,
>> + source_addr_mode:2;
>> +#elif defined(__BIG_ENDIAN_BITFIELD)
>> + u16 reserved:1,
>> + intra_pan:1,
>> + ack_request:1,
>> + frame_pending:1,
>> + security_enabled:1,
>> + type:3,
>> + source_addr_mode:2,
>> + version:2,
>> + dest_addr_mode:2,
>> + reserved2:2;
>> +#else
>> +#error "Please fix <asm/byteorder.h>"
>> +#endif
> I'm wondering if using 2 u8's might read better so at least the reserved
> fields match?
> like in the following:
> http://lxr.free-electrons.com/source/drivers/net/ethernet/sun/niu.h#L2706
They would look contiguous, but they won't be contiguous in memory.
Declarig the reserved field as u8:3 will cause the allocator to move that
three-bit field to the next byte in memory, so that's certainly unwanted.
Using two u8s would also betray that this field is treated as a 16 bit
entity by the standard and the protocol, and we couldn't cast the header
pointer to u16* to get the raw value of the fc field, because u16 forces
the compiler to allocate the struct as though the bitfield sequence was
one u16.
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
