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

[Gleb Smirnoff]

On Tue, Mar 05, 2013 at 07:25:54AM -0800, mdf at FreeBSD.org wrote:
m> On Tue, Mar 5, 2013 at 1:43 AM, Bruce Evans <brde at optusnet.com.au> wrote:
m> > Why?  There is no existing practice for [bool] in the kernel.  There is some
m> > in the Linux kernel :-).
m> 
m> IMO this is the problem with style always conforming to existing code.
m>  There is no way to introduce new concepts.
m> 
m> bool may be slightly pessimistic from the standpoint of compiler
m> forcing 0/1.  However, since C is weakly typed, we "should" all have
m> been writing our control statements that take a boolean to evaluate to
m> a boolean argument, as implied by the style guideline that '!' is only
m> applied to boolean statements.  That style recommendation is often not
m> followed; e.g. there's plenty of code like if (!error) (I found 762
m> instances in sys/).
m> 
m> To unpack what I said, without a bool type if (error) was style-weird
m> since it wasn't a boolean used in a boolean expression, but C was
m> "clever" and decided how to do that, instead of requiring the boolean
m> expression if (error != 0).  style(9) had an example of a proper
m> boolean but that form is used less frequently than the shorter C idiom
m> of if (error).  (17942 instances of if (error) versus 3168 instances
m> of the more style(9)-correct if (error != 0)).
m> 
m> Types are there to document things for humans, with a side effect of
m> documenting things for the hardware.  Efficiency is important but
m> rarely king; for example no one went around changing loop counters
m> form int to long for 64-bit hardware even though some operations on
m> long are faster since they don't need to sign-extend (and possibly
m> some operations on long are slower since on x86 the instruction may be
m> more bits, and icache is so important.  But I doubt the experiment was
m> even done).
m> 
m> bool serves the purpose of documenting exactly that something is
m> true/false and no other value.  bool++ was a lazy way of writing bool
m> = true, and suffered from a theoretical problem of overflow when bools
m> were ints and not a language-defined type with explicit semantics.
m> 
m> Anyways, my long-winded point was that the C language has evolved.  If
m> our highest style guide is that we preserve existing style, we will
m> never use new language features since they never used to exist.  So I
m> don't think that the absence of any code examples is a reason to
m> forbid code.

+1

Thanks for typing the long explanation, Matthew.

-- 
Totus tuus, Glebius.