linux-kernel - Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount

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+55aFz7k5zUvJdZxpZgCgfx_-PT+f-9J50hnC1i3x=8_dXkBw@mail.gmail.com>
Date:	Sat, 31 Aug 2013 10:16:52 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	George Spelvin <linux@...izon.com>
Cc:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Waiman Long <waiman.long@...com>
Subject: Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless
 update of refcount

On Fri, Aug 30, 2013 at 8:06 PM, George Spelvin <linux@...izon.com> wrote:
> Just noticing that you are adding several functions that return a boolean
> value as an int.  And a "gotref" local variable.
>
> Is that just not wanting to bother with thse newfangled C99 innovations,
> or do you dislike the "bool" type for some reason?

I don't use "bool" in code I write. I don't think it adds any actual
value, and I think the data type is badly designed and of dubious
value in C. It has very few actual advantages.

That said, it's not like I *hate* the type, and I won't remove bool
from code other people write. I just think it's superfluous and
stupid, and another case of C++ people thinking too much "this is a
cool feature" without then actually doing it well. The C people then
picked it up because it was less onerous than some other C++ features,
and all the compilers had the logic anyway.

If "bool" had real advantages (like having a dense array
representation, for example), that would be one thing. It doesn't.
Sure, now you can take an address of a bool (which you couldn't
generally do efficiently if it really was a bit array), but it also
means that in practice, "bool" is normally nothing but "char" with
some really odd and special implicit type casting rules.

I doubt most people really even understand how "bool" casting works.

And bool is actually really *dangerous* to use if you don't understand
it. There are people who use "bool", but then because they want to be
portable, they have a compatibility #ifdef or other configuration
thing that does something like

   typedef int bool;
   #define true 1
   #define false 0

and it will actually work. Most of the time. And then the semantic
differences from a _real_ C compiler that supports the C99 _Bool/bool
type are really really subtle.

IOW, bool has very few real upsides, and it has a real downside: it's
subtle, and people really never even seem to _realize_ just how subtle
it is.  I suspect that if you ask ten random average C programmers if
the above is equivalent to stdbool.h, nine of them will say "sure".

And they'd be *COMPLETELY* wrong.

So no. I'm definitely not a fan of bool. I think there are better
types, and I think there are better ways to document things.

                     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/