linux-kernel - Re: [PATCH v8 net-next 1/3] filter: add Extended BPF interpreter and converter

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: <9b7e4f89-468b-4d02-91ea-3e91d61934bd@email.android.com>
Date:	Mon, 10 Mar 2014 19:20:52 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Miller <davem@...emloft.net>
CC:	ast@...mgrid.com, dborkman@...hat.com,
	Ingo Molnar <mingo@...nel.org>, Will Drewry <wad@...omium.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Hagen Paul Pfeifer <hagen@...u.net>,
	Jesse Gross <jesse@...ira.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Eric Dumazet <edumazet@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	penberg@....fi, Arjan van de Ven <arjan@...radead.org>,
	Christoph Hellwig <hch@...radead.org>,
	Pavel Emelyanov <xemul@...allels.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH v8 net-next 1/3] filter: add Extended BPF interpreter and converter

Bool vs bitfield are orthogonal, at least under gcc, unless I'm completely out to sea.  It is probably not a good idea to create a bitfield when it doesn't buy you anything, lest you generate rmw instructions when byte stores would do.

On March 10, 2014 7:02:18 PM PDT, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>On Mon, Mar 10, 2014 at 6:51 PM, David Miller <davem@...emloft.net>
>wrote:
>> From: Alexei Starovoitov <ast@...mgrid.com>
>> Date: Sun,  9 Mar 2014 23:04:02 -0700
>>
>>> +     unsigned int            jited:1;
>>
>> The C language has a proper type for boolean states, please therefore
>> use 'bool', true, and false.
>
>No, the C standard actually has no such thing.
>
>In a structure, a bitfield is actually better than bool, because it
>takes only one bit. A "bool" takes at least a byte.
>
>Now, in this case it may not be an issue (looks like there are no
>other uses that can use the better packing, so bit/byte/word is all
>the same), but I really really want to make it clear that it is not at
>all true that "bool" is somehow better than a single-bit bitfield. The
>bitfield can pack *much* better, and I would actually say that it's
>generally a *better* idea to use a bitfield, because you can much more
>easily expand on it later by adding other bitfields.
>
>There are very few actual real advantages to "bool". The magic casting
>behavior is arguably an advantage (the implicit cast in assigning to a
>bitfield truncates to the low bits, the implicit cast on assignment to
>"bool" does a test against zero), but is also quite arguably a
>possible source of confusion and can cause problems down the line when
>converting from bool to a bitfield (for the afore-mentioned packing
>reasons).
>
>So please don't sell "bool" as some kind of panacea. It has at least
>as many problems as it has advantages.
>
>I would generally suggest that people only use "bool" for function
>return types, and absolutely nothing else. Seriously.
>
>              Linus

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.
--
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/