Brandon S. Allbery wrote:
> De facto, for most if not all Linux-supported architectures, if you put
> larger members before smaller members, gcc won't add padding; ...
> ....
> You can continue to rely on this; or you can use __attribute__((packed))
> and be certain that it will work correctly on any future architectures with
> "unusual" alignment requirements. (Personally, I don't really expect to
> see many of the latter --- but I'm no architecture guru, and for all I know
> it may be the wave of the future.)
Regardless of the "de facto" behaviour of current versions of gcc
there is a bit more to it. If __attribute__((packed)) is present then
a compiler may generate a somewhat different code to access structure
elements. Without it, if you have an "unlucky" layout, you may get
"unaligned traps". Those with Alphas are quite aware that before this
attribute was added to 'struct partition' in genhd.h then every
attempt to use 'fdisk' resulted in a number of "unaligned access"
messages.
This is just an example and moreover not that important apart of that
that it was higly visible. You may get these traps on other
architectures as well; the difference are that:
- kernels are quiet about that save Alpha
- on x86 these misaligned accesses are not that costly but elsewhere
they can be quite a drag.
Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:05 EST