LKML Archive on
help / color / mirror / Atom feed
From: Jamie Lokier <>
To: Arnd Bergmann <>
Cc: Bob Copeland <>, Pavel Machek <>,,
Subject: Re: [PATCH 1/7] omfs: define filesystem structures
Date: Sat, 29 Mar 2008 15:29:20 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Arnd Bergmann wrote:
> Actually, we don't normally add the attribute((packed)) in cases like
> this one, where you already have manual padding in it. Marking this
> structure packed would only cause a small performance loss on accesses
> of its members on certain architectures, but not have an impact on
> correctness.
> No architecture supported by Linux requires higher than natural alignment
> for any integer types, and a lot of other code would break otherwise.

That's not quite true.  Some architectures supported by Linux add
"external" padding to the size and alignment of a structure.

	struct my_subtype {
		unsigned char st1, st2;

On Linux/ARM, sizeof(my_subtype) == 4 and __alignof__(my_subtype) == 4.
On Linux/x86, sizeof(my_subtype) == 2 and __alignof__(my_subtype) == 1.

This will break code which expects them to pack into an array, or
which is accessing this structure from a 2-byte aligned address.

This also effects structures containing other structures:

	struct my_type {
		unsigned char a, b, c, d;
		struct my_subtype st[2];
		unsigned char e, f, g, h;

On Linux/ARM, sizeof(my_type) == 16 and __alignof__(my_subtype) == 4.
On Linux/ARM, sizeof(my_type) == 12 and __alignof__(my_subtype) == 1.

This did break one of my programs on Linux.  I had to decide between
using __attribute__((packed)) and losing portability, or stop using a
struct to access the data which was ugly but portable (the structures
had a lot more fields than this example).

-- Jamie

  reply	other threads:[~2008-03-29 15:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-27  0:45 Bob Copeland
2008-03-28 20:19 ` Pavel Machek
2008-03-28 23:18   ` Bob Copeland
2008-03-29  3:15     ` Arnd Bergmann
2008-03-29 15:29       ` Jamie Lokier [this message]
2008-03-30  3:16         ` Bob Copeland
2008-04-12 22:58 Bob Copeland
2008-04-13  8:03 ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 1/7] omfs: define filesystem structures' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).