3 ms·
The standard permits padding structures, but not reordering their members. That's why container_of is necessary (to avoid constantly-updated manual offset calcu
by yew 12y ago
The standard permits padding structures, but not reordering their members. That's why container_of is necessary (to avoid constantly-updated manual offset calculations or writing redundant code). Any implementation that reorders structure members is non-compliant (and likely incompatible with much existing code).
To quote the relevant section (C99 6.7.2.1.13, same wording present in C89):
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 are 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 be unnamed padding within a structure object, but not at its beginning.
I'll repeat that I consider direct casts to be somewhat idiomatic. Macros are more traditional for offset members.
- eps 12y agoUsing container_of is better because it doesn't lead to a broken code when someone (accidentally) splices another field at the top of the struct. Or put differently, direct casting comes with an assumption, while container_of doesn't. The fewer obscure assumptions are there in the code, the better. I think we can all agree on that :)
- yew 12y agoI can agree with that almost without reservation :)