Date: Tue, 5 Mar 2013 19:30:10 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: mdf@FreeBSD.org Cc: Davide Italiano <davide@freebsd.org>, src-committers@freebsd.org, John Baldwin <jhb@freebsd.org>, attilio@freebsd.org, Bruce Evans <brde@optusnet.com.au>, svn-src-projects@freebsd.org Subject: Re: svn commit: r247710 - projects/calloutng/sys/kern Message-ID: <20130305153010.GL48089@FreeBSD.org> In-Reply-To: <CAMBSHm_AUjjMgzoVoMxM=awudKekbEHmzmHda%2BBCX14Dgqtjag@mail.gmail.com> References: <201303031339.r23DdsBU047737@svn.freebsd.org> <201303041521.06557.jhb@freebsd.org> <CAJ-FndBvLD_fU1ZZ3cGNtChfdtXyuBRt4Z_ci8daS08ZYdOKzg@mail.gmail.com> <201303041620.52100.jhb@freebsd.org> <20130305201211.M902@besplex.bde.org> <CAMBSHm_AUjjMgzoVoMxM=awudKekbEHmzmHda%2BBCX14Dgqtjag@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 05, 2013 at 07:25:54AM -0800, mdf@FreeBSD.org wrote: m> On Tue, Mar 5, 2013 at 1:43 AM, Bruce Evans <brde@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130305153010.GL48089>