Re: sizeof problem in kernel modules

[Alan Shutko <ats@acm.org>]

"Richard B. Johnson" <root@chaos.analogic.com> writes:

> This means that it must be some place else than where it's denoted
> in a visual representation of the structure.

No, that's not true.

ISO/IEC 9899:1990 6.5.2.1:

  As discussed in 6.1.2.5, a structure is a type consisting of a
  sequence of named members, whose storage is allocated in an ordered
  sequence, and a union [stuff we don't care about].

  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 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 therefore be unnammed padding withing a structure object,
  but not at its beginning, as necessary to achieve the appropriate
  alignment.

  There may also be unnamed padding at the end of a structure or
  union, as necessary to achieve the appropriate alignment were the
  structure or union to be an element of an array.

You can look at other things too... you can memcpy structures, pass
them into functions, call sizeof, put them in arrays... it _is_ a
physical representation.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Conscience is what hurts when everything else feels so good.