Re: sizeof problem in kernel modules

[Alan Shutko]

"Richard B. Johnson" <[e-mail]> writes:

> > 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].
> >
> 
> Does "ordered sequence" mean "incremental"? I think not.

It does mean there is an order, as defined below.

>  
> >   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.
> 
> 
> Really?? Did you TYPE this in or did you copy it from somewhere??

I typed it in and forgot an "are".  Forgive me, but this doesn't
change the point, and you could have easily looked in the standard
yourself to see where I mistyped.

> And... If this was a part of a C specification

Which it is.

> it would prevent the inclusion of const data within a structure
> unless the entire structure was of type const.

No.  The C standard does not guarantee that const items be placed in
RO memory.  It does not even require that the host have RO memory, or
that an implementation do the same thing with a const object as a
const member of a structure.

> >   There may therefore be unnammed padding withing a structure object,

> Unnamed and within are spelled incorrectly. This is not a valid
> document.

Geez, would you rather I scan it for you?  

> This way, the compiler "knows" where things are and handles duplication
> accordingly.

Of course it knows where things are, since a structure is a single
contiguous range of memory, according to the standard.

Would you care to offer counter citations?  Have you even looked at
the standard?

-- 
Alan Shutko <[e-mail]> - In a variety of flavors!
Please keep your hands off the secretary's reproducing equipment.