On Fri, Nov 22, 2002 at 02:08:12PM +0100, Marco Molteni wrote:
> what's wrong with this:
>
> struct foo {
> ....
> } __attribute__ packed
>
> I think the only problem is that __attribute__ is a ggcism and is not
> portable, right?
Yes (well, other than the missing parentheses around "packed" :-)).
That is a *sufficient* problem for Ethereal to reject it, as we support
compilation with compilers other than GCC; no GCCism's, please, unless
1) they're #if'ed or #ifdeffed so that they're only used with
GCC
and
2) the code works even if the GCCisms aren't being used.
and 2) is *not* the case here.
Another problem there is, of course, that you must remember to put in
explicit padding when necessary, as "__attribute__((packed))" means the
structure will be packed and stuff will *not* be put on natural
boundaries.
> > - Your processor's host byte order differs from network byte order,
> > e.g. IA32.
>
> Should be enough to always use ntohs() and ntohl(), right?
Yes.
But if your processor's host byte order differs from *little-endian*
byte order, those won't help you for packets with little-endian data.
If people *really* insist on grabbing pointers to packet data and
casting them to structure pointers (*I* have no problem with extracting
fields directly with "tvb_get_guint8()", "tvb_get_ntohs()",
"tvb_get_ntohl()", "tvb_get_letohs()", "tvb_get_letohl()", and the like
- or using "proto_tree_add_item()" and letting *it* extract the field
value - so I don't see why there's a need to do the pointer-casting
stuff) they can use the macros from "epan/pint.h", which take pointers
to 8-bit, 16-bit, 24-bit, and 32-bit fields, and fetch data in either
big-endian or little-endian order even if they're unaligned (as they
assemble the value a byte at a time).
