Date: Wed, 6 Mar 2013 03:39:13 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> 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: <20130306024642.M2179@besplex.bde.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, 5 Mar 2013 mdf@FreeBSD.org wrote:
> On Tue, Mar 5, 2013 at 1:43 AM, Bruce Evans <brde@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.
Yes, it is hard to change the style of something 5.8 million lines long
(that's just the kernel sources. 4.4Lite2 was a only 660000 lines).
Change a rule affecting 0.1% of lines perfectly formatted in the old
style and you instantly have 5800 new style bugs.
> 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/).
130 in Lite2. The rules against them seem to be having an effect,
since their expansion factor of 5.96 is less than the kernel expansion
factor if 8.78.
> 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).
This is technically an integer expression (even if `error' was bool
and 0 was spelled 'false', they would promote to int in the expression).
> 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)).
'if (error)' was the old style, and the 3168 instance of 'if (error != 0)
are partly the result of adding an example of the latter in style(9).
There seems to be no rule against either in in style(9). Old code even
used 'if (error = foo())' (which compilers now warn about), and the only
instance of 'error' in the 4.4BSD-Lite2 style guide gives an example of
that:
Lite2:
@ /* No spaces after function names. */
@ if (error = function(a1, a2))
@ exit(error);
FreeBSD:
@ No spaces after function names. Commas have a space after them. No spa-
@ ces after `(' or `[' or preceding `]' or `)' characters.
@
@ error = function(a1, a2);
@ if (error != 0)
@ exit(error);
Perhaps more than half of the 3168 are the result of a phk sweep to change
to the latter. Other people and OS's more often changed to
`if ((error = foo()) != 0)' which matches the original rather cryptic
style better.
> bool serves the purpose of documenting exactly that something is
> true/false and no other value.
I think there aren't enough pure bools to make much difference. All
the (error [!= 0]) examples are for integer expressions obfuscated as
boolean expressions. This makes the style change to it easier but
less useful.
> 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.
I describe it as "micro-optimizing for pdp-11", and always wrote it as
"var = TRUE". Requiring using stdbool also breaks the style of old
code that was careful about this, by requiring changing the spelling
of "true". Not requiring it or not enforcing the requirement leaves a
ixture of styles, with a half-life for the old style of much longer
than 15 years, as shown by the 17942:3168 for (error) vs (error != 0).
This ratio would probably be little different if the rule hadn't been
changed. You would have to enforce it to eradicate the 17942 lines,
and no one would like strict enforcement of style(9), especially just
after someone adds a new rule to it because they don't like the old
style.
> 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.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130306024642.M2179>