Re: What is the problem with my arp structure?

From: Chris Croughton (chris_at_keristor.net)
Date: 12/17/04 

Date: Fri, 17 Dec 2004 18:31:59 +0000

On 17 Dec 2004 08:26:46 -0800, Muhammad Farooq-i-Azam
   <farooq.i.azam@gmail.com> wrote:

> I am trying to define an arp structure but having problem
> doing so. I think I have define the correct arp structure but
> I find myself in a strange problem. The size of structure that
> I have defined is 28 bytes, but it is reported to be 32 bytes by
> the sizeof() call.

Alignment of variables is your problem.

> Size of arp.src_hwaddr is 6 bytes. Its address is 0xbfffe848.
> Therefore, the size of the next structure member should be
> 0xbfffe848+6 = 0xbfffe84e.

However, what follows src_hwaddr is a 32 bit value (src_protoaddr). It
seems that on whatever machine you are using 32 bit variables have to be
aligned on a 4-byte boundary, so a 'hole' is left to bring the address
to the correct boundary.

You may be able to get round this with a #pragma or a (non-standard)
attribute, or with a compiler flag (although you have to be careful with
that since it will affect every structure in that module so every other
module needs to use the same flag). Look in your compiler documentation
for terms like 'pack' and 'packed'. However, not only is this
nonstandard but it also isn't guaranteed, your processor may mot work
with misaligned data access (the i86 processors will access unaligned
data, but more slowly, but RISC ones will often fault if you try to
access a 32 bit value which crosses word boundaries).

The C standard deliberately doesn't define how or whether packing is
done. See section 6.7.2.1:

  11 Each non-bit-field member of a structure or union object is
     aligned in an implementation defined manner appropriate to its
     type.

  12 Within a structure object, the non-bit-field members and the
     units in which bit-fields reside have addresses that increase in
     the order in which they are declared. A pointer to a structure
     object, suitably converted, points to its initial member (or if
     that member is a bit-field, then to the unit in which it
     resides), and vice versa. There may be unnamed padding within a
     structure object, but not at its beginning.

Any amount of 'padding' can be within a structure, with the exception of
bit fields, so getting a structure which maps onto a specific byte
sequence is not defined. The only sure way to hadle it is to extract
the bytes from memory and reassemble them yourself into the specified
fields (that way you can also handle the 'endianness' in a portable
way).

When dealing with network structures I have written functions to extract
from and write to byte arrays 32 and 16 bit values. For instance:

  unsigned long getData16(unsigned char *data, int offset)
  {
    return (data[offset] << 8) | data[offset+1];
  }

  unsigned long getData32(unsigned char *data, int offset)
  {
    return (getData16(data, offset) << 16) | getData16(data, offset+2);
  }

  void putData16(unsigned char *data, int offset, unsigned long val)
  {
    data[offset] = (val >> 8) & 0xFF;
    data[offset+1] = val & 0xFF;
  }

  void putData32(unsigned char *data, int offset, unsigned long val)
  {
    putData16(data, offset, val >> 16);
    putData16(data, offset+2, val);
  }

Then I use the data buffer and explicit offsets to put and get the
fields and don't have to worry about endianness or alignment...

Chris C

Relevant Pages