svn commit: r247710 - projects/calloutng/sys/kern

[mdf at FreeBSD.org]

On Tue, Mar 5, 2013 at 1:43 AM, Bruce Evans <brde at optusnet.com.au> wrote:
> Why?  There is no existing practice for [bool] in the kernel.  There is some
> in the Linux kernel :-).

IMO this is the problem with style always conforming to existing code.
 There is no way to introduce new concepts.

bool may be slightly pessimistic from the standpoint of compiler
forcing 0/1.  However, since C is weakly typed, we "should" all have
been writing our control statements that take a boolean to evaluate to
a boolean argument, as implied by the style guideline that '!' is only
applied to boolean statements.  That style recommendation is often not
followed; e.g. there's plenty of code like if (!error) (I found 762
instances in sys/).

To unpack what I said, without a bool type if (error) was style-weird
since it wasn't a boolean used in a boolean expression, but C was
"clever" and decided how to do that, instead of requiring the boolean
expression if (error != 0).  style(9) had an example of a proper
boolean but that form is used less frequently than the shorter C idiom
of if (error).  (17942 instances of if (error) versus 3168 instances
of the more style(9)-correct if (error != 0)).

Types are there to document things for humans, with a side effect of
documenting things for the hardware.  Efficiency is important but
rarely king; for example no one went around changing loop counters
form int to long for 64-bit hardware even though some operations on
long are faster since they don't need to sign-extend (and possibly
some operations on long are slower since on x86 the instruction may be
more bits, and icache is so important.  But I doubt the experiment was
even done).

bool serves the purpose of documenting exactly that something is
true/false and no other value.  bool++ was a lazy way of writing bool
= true, and suffered from a theoretical problem of overflow when bools
were ints and not a language-defined type with explicit semantics.

Anyways, my long-winded point was that the C language has evolved.  If
our highest style guide is that we preserve existing style, we will
never use new language features since they never used to exist.  So I
don't think that the absence of any code examples is a reason to
forbid code.

Cheers,
matthew