Peter Edwards wrote: > > He's making the valid point that for: > > > > struct foo *fee; > > > > It's possible that: > > > > sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0])) > > 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[1] 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?!? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
