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: <CA+55aFx7rdm9DGOTTgAKTHNkdfrvQYhT9PRs5MhUPr1gQzWEgA@mail.gmail.com>
Date:	Mon, 10 Mar 2014 19:02:18 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	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>,
	Peter Anvin <hpa@...or.com>,
	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

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
--
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/