linux-kernel - Re: Process to push changes to include/linux/types.h

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] [day] [month] [year] [list]

Message-ID: <alpine.LNX.2.01.1010151713060.30823@obet.zrqbmnf.qr>
Date:	Fri, 15 Oct 2010 17:24:44 +0200 (CEST)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	Andreas Gruenbacher <agruen@...e.de>
cc:	Andi Kleen <andi@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Eric Paris <eparis@...hat.com>, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, davem@...emloft.net
Subject: Re: Process to push changes to include/linux/types.h


On Friday 2010-10-15 16:44, Andreas Gruenbacher wrote:
>On Friday 15 October 2010 16:26:17 Andi Kleen wrote:
>> > 64-bit values align to 4-byte boundaries on some 32-bit architectures like
>> > x86 
>> AFAIK it's only on x86, no other architecture made this mistake in their
>> 32bit ABI. But of course x86 is kind of important ...
>
>I don't know of any other examples; all the architectures I tried "got it 
>right" except x86.

I don't think x86 has done anything wrong. It processes stuff in
32-bit chunks, so why should one waste space for aligning a 64-bit
entity to 8? On sparcv9, a long double also has an alignment
smaller than its size.

If you don't like that, you can always patch up gcc, because
alignment is after all a decision made by the compiler. In that
regard, it might be worth checking out the gcc machine description
files and find out why people specified an alignment of 8 for
uint64_t anything but i?86.
--
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/