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: <Z824SgB9Dt5zdWYc@visitorckw-System-Product-Name>
Date: Sun, 9 Mar 2025 23:48:26 +0800
From: Kuan-Wei Chiu <visitorckw@...il.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: David Laight <david.laight.linux@...il.com>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	Laurent.pinchart@...asonboard.com, airlied@...il.com,
	akpm@...ux-foundation.org, alistair@...ple.id.au,
	andrew+netdev@...n.ch, andrzej.hajda@...el.com,
	arend.vanspriel@...adcom.com, awalls@...metrocast.net, bp@...en8.de,
	bpf@...r.kernel.org, brcm80211-dev-list.pdl@...adcom.com,
	brcm80211@...ts.linux.dev, dave.hansen@...ux.intel.com,
	davem@...emloft.net, dmitry.torokhov@...il.com,
	dri-devel@...ts.freedesktop.org, eajames@...ux.ibm.com,
	edumazet@...gle.com, eleanor15x@...il.com,
	gregkh@...uxfoundation.org, hverkuil@...all.nl,
	jernej.skrabec@...il.com, jirislaby@...nel.org, jk@...abs.org,
	joel@....id.au, johannes@...solutions.net, jonas@...boo.se,
	jserv@...s.ncku.edu.tw, kuba@...nel.org, linux-fsi@...ts.ozlabs.org,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org, linux-mtd@...ts.infradead.org,
	linux-serial@...r.kernel.org, linux-wireless@...r.kernel.org,
	linux@...musvillemoes.dk, louis.peens@...igine.com,
	maarten.lankhorst@...ux.intel.com, mchehab@...nel.org,
	mingo@...hat.com, miquel.raynal@...tlin.com, mripard@...nel.org,
	neil.armstrong@...aro.org, netdev@...r.kernel.org,
	oss-drivers@...igine.com, pabeni@...hat.com,
	parthiban.veerasooran@...rochip.com, rfoss@...nel.org,
	richard@....at, simona@...ll.ch, tglx@...utronix.de,
	tzimmermann@...e.de, vigneshr@...com, x86@...nel.org,
	yury.norov@...il.com
Subject: Re: [PATCH v3 00/16] Introduce and use generic parity16/32/64 helper

On Fri, Mar 07, 2025 at 12:07:02PM -0800, H. Peter Anvin wrote:
> On March 7, 2025 11:53:10 AM PST, David Laight <david.laight.linux@...il.com> wrote:
> >On Fri, 07 Mar 2025 11:30:35 -0800
> >"H. Peter Anvin" <hpa@...or.com> wrote:
> >
> >> On March 7, 2025 10:49:56 AM PST, Andrew Cooper <andrew.cooper3@...rix.com> wrote:
> >> >> (int)true most definitely is guaranteed to be 1.  
> >> >
> >> >That's not technically correct any more.
> >> >
> >> >GCC has introduced hardened bools that intentionally have bit patterns
> >> >other than 0 and 1.
> >> >
> >> >https://gcc.gnu.org/gcc-14/changes.html
> >> >
> >> >~Andrew  
> >> 
> >> Bit patterns in memory maybe (not that I can see the Linux kernel using them) but
> >> for compiler-generated conversations that's still a given, or the manager isn't C
> >> or anything even remotely like it.
> >> 
> >
> >The whole idea of 'bool' is pretty much broken by design.
> >The underlying problem is that values other than 'true' and 'false' can
> >always get into 'bool' variables.
> >
> >Once that has happened it is all fubar.
> >
> >Trying to sanitise a value with (say):
> >int f(bool v)
> >{
> >	return (int)v & 1;
> >}    
> >just doesn't work (see https://www.godbolt.org/z/MEndP3q9j)
> >
> >I really don't see how using (say) 0xaa and 0x55 helps.
> >What happens if the value is wrong? a trap or exception?, good luck recovering
> >from that.
> >
> >	David
> 
> Did you just discover GIGO?

Thanks for all the suggestions.

I don't have a strong opinion on the naming or return type. I'm still a
bit confused about whether I can assume that casting bool to int always
results in 0 or 1.

If that's the case, since most people prefer bool over int as the
return type and some are against introducing u1, my current plan is to
use the following in the next version:

bool parity_odd(u64 val);

This keeps the bool return type, renames the function for better
clarity, and avoids extra maintenance burden by having just one
function.

If I can't assume that casting bool to int always results in 0 or 1,
would it be acceptable to keep the return type as int?

Would this work for everyone?

Regards,
Kuan-Wei

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ