Warren Brown [mailto:wkb / airmail.net] wrote:

> > I think nesting a struct simply tells C
> > to allocate an additional sizeof(inner)
> > in the outer struct, and the compiler
> > then translates an outer.inner.whatever
> > reference to access the correct memory
> > in outer. But that's mostly a guess.
> 
>     This is generally correct.  IIRC, in C structure members 
> are guaranteed to be stored in the same order they were 
> declared.  The only thing that might end up being a problem 
> is alignment issues.  A C compiler is allowed to insert 
> additional filler in a structure to guarantee alignment.  I 
> could imagine a C compiler inserting filler to word align a 
> nested structure, even if the data members of that structure 
> did not require it.  For example:
> 
> typedef struct { char b; } inner;
> typedef struct { char a; inner c; char d; } outer;
> 
>     ...could be stored as "afbfd" ('f'=filler) instead of 
> "abd".  My guess would be that this occurs rarely if ever in 
> practice, but I believe that it is possible.

Thanks for the info!

I could definitely see struct alignment as being a potential problem, but it
would seem that DL must handle it somehow already, since it could also be a
problem for plain old (no nesting) structs, right?


Nathaniel

<:((><