[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080329152920.GA10653@shareable.org>
Date: Sat, 29 Mar 2008 15:29:20 +0000
From: Jamie Lokier <jamie@...reable.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Bob Copeland <me@...copeland.com>, Pavel Machek <pavel@....cz>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 1/7] omfs: define filesystem structures
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists