Re: [PATCH] Introduce compat_u64 and compat_s64 types

[Arnd Bergmann]

On Friday 15 June 2007, Matthew Wilcox wrote:
> Here's a program which illustrates the source of confusion:
> 
> #include <stdio.h>
> #include <stddef.h>
> 
> typedef unsigned long long __attribute__((aligned(4))) compat_u64;
> 
> struct foo {
>         int y;
>         unsigned long long __attribute__((aligned(4))) x;
> };
> 
> struct bar {
>         int y;
>         compat_u64 x;
> };
> 
> int main(void)
> {
>         printf("offset of foo->x is %lu\n", offsetof(struct foo, x));
>         printf("offset of bar->x is %lu\n", offsetof(struct bar, x));
>         return 0;
> }
> 
> output (on ia64, and I'm told other 64-bit platforms) is:
> 
> $ ./test 
> offset of foo->x is 8
> offset of bar->x is 4
> 
> I'll try and come up with some wording that works for the GCC manual.



I just talked to Ulrich Weigand, who explained to me that
__attribute__((packed)) should not be specified on a typedef that is
not also a struct/union/enum definition, because it can not change the
type anyway.

Also, the attribute((aligned(x))) works differently in a typedef than
in a field or variable declaration:

In your struct foo, __attribute__((aligned(4))) does not have any
effect because the attribute on a field declaration will only increase
the alignment if you specify a larger value than the default alignment
for the member type.

In struct bar, you have two members that both have type with a default
alignment of 4, because the typedef overwrote the default alignment
for the compat_u64 type.

	Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/