Peter Edwards wrote:
> > He's making the valid point that for:
> > struct foo *fee;
> > It's possible that:
> > sizeof(struct foo) != (((char *)&fee) - ((char *)&fee))
> Wouldn't that mean
> .. struct X *xarr = malloc(sizeof (struct X) * arrayLen);
> wouldn't produce a useable array of struct X of length arrayLen?
> That can't be right.
No, it doesn't mean that, because there *is* end padding in the
size calculation. That's kind of the whole point of this thread.
In the directory entry example, the last element is a d_name
that's an overlay array that's much longer than it appears (it
is always at least 4 bytes). This is because it's meant to work
with other than C99 (which permits an array with a declared size
of 0). It's necessary for the code to know the offset of the
start of that elemenet from the start of the structure, and that
offset is *NOT* "sizeof(struct) - 1", as you would naievely believe,
as if there were no end padding, because the total size of the
structure is not always going to be evenly divisible by the number
of bytes between alignment boundaries.
Does this make more sense?!?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message