linux-kernel - Re: [PATCH] Introduce compat_u64 and compat

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200706151552.20915.arnd@arndb.de>
Date:	Fri, 15 Jun 2007 15:52:20 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Matthew Wilcox <matthew@....cx>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dave Airlie <airlied@...ux.ie>, linux-arch@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] Introduce compat_u64 and compat_s64 types

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/