linux-kernel - Re: [PATCH 02/10] x86, asm: use bool for bitops and other assembly outputs

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: <02ee64ce-257a-ba93-1f49-6877f5e4f6db@zytor.com>
Date:	Wed, 8 Jun 2016 01:55:19 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>
Cc:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH 02/10] x86, asm: use bool for bitops and other assembly
 outputs

On 06/08/16 01:33, Ingo Molnar wrote:
> 
> Note that this particular build error was introduced by b0bdba9825fe, a later 
> patch in this series - but in generaly I'm uneasy about allowing function 
> signatures diverge between architectures.
> 

For the bitops, they already do: PowerPC, for example, have "unsigned
long" in places where x86 has "int".  This is obviously undesirable, but
apparently we have not found it enough of a problem to deal with.  One
could easily argue the ppc definition is the better one; I was myself
considering promoting the x86 side to "long" to handle enormous bitmaps.
 At the same time, it is hard to avoid the fact that ppc has unsigned
bitops operations and x86 has signed ones when they are both native
instructions.

	-hpa