| 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
| ||
|
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/
Powered by blists - more mailing lists