[Click] CLICK_BYTE_ORDER

Beyers Cronje bcronje at gmail.com
Wed Aug 2 10:32:36 EDT 2006


Koen,


I need to write a struct for a new custom header, somewhat like
> include/clicknet/ip.h
> But I don't get why in ip.h one changes the order of ip_v and ip_hl
> depending on CLICK_BYTE_ORDER.
> The bits inside a byte are the same for Little- and Big Endian
> machines, right? So first ip_v and then ip_hl looks right to me for
> no-mather-what-endian machine... not?


No. The first byte contain bit fields. Bit order usually follows the same
endianness as the byte order for a given system. That is, in a big endian
system the most significant bit is stored at the lowest bit address; in a
little endian system, the least significant bit is stored at the lowest bit
address. According to IP standard, version is the most significant four bits
of the first byte of an IP header. ihl is the least significant four bits of
the first byte of the IP header.

See http://www.linuxjournal.com/node/6788/print for a good article on the
subject.

And can anyone tell me about what datatypes I should use? There is
> uint8_t, uint16_t, uint32_t, atomic_uint32_t, unsigned, ... (but no
> integer, long, char, ... ??)
> Where can I find info on this? (didn't find it in de programming
> manual or on doxygen) And what is atomic, and when should I use it?


 I think the uintX_t are typedefs, but I might be wrong. You can use either.
atomic integers for synchronization, only one processor can write/read
atomic interger at a time.

Beyers


More information about the click mailing list