From owner-svn-src-projects@FreeBSD.ORG Tue Mar 5 15:25:56 2013 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 119FD18C; Tue, 5 Mar 2013 15:25:56 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by mx1.freebsd.org (Postfix) with ESMTP id 6F662863; Tue, 5 Mar 2013 15:25:55 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id cr7so1955172qab.3 for ; Tue, 05 Mar 2013 07:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=e7XwLBqoWON7UBmwP9GCHd4ouH5juLCqv4c3BVKG5ts=; b=KTBTt50diTKWckrBSh0Pys0v/OCJMWU103uaEY5DiKHauYhsfcGzN6NCraUParzDyv 3/zS553t0fUeKilypB+vWitqVP4SCmLszA5DVQ+MIX9pELKnnp6hu++ZYxZG0XOzsmIB 2PFzbQXweMChxhGCGsaK3R52/fEDtOca69oir+0RWq/I0cUgU7uFFlEfgyyG8wszIbPH ETr2YczVJxI/mWwIS9giOjACtc+MJ3wNcP+SfXtWssVHMWv7SRjtCZa9nM6wE10PwOfs kI8n0tDlsF6Izd80CrCpa9VzwS27mnrnLsKsB+JRMGRoYVDEOwARjsqVwrbwdS6GLgVq 7z9Q== MIME-Version: 1.0 X-Received: by 10.229.177.224 with SMTP id bj32mr8534276qcb.102.1362497154377; Tue, 05 Mar 2013 07:25:54 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.229.179.42 with HTTP; Tue, 5 Mar 2013 07:25:54 -0800 (PST) In-Reply-To: <20130305201211.M902@besplex.bde.org> References: <201303031339.r23DdsBU047737@svn.freebsd.org> <201303041521.06557.jhb@freebsd.org> <201303041620.52100.jhb@freebsd.org> <20130305201211.M902@besplex.bde.org> Date: Tue, 5 Mar 2013 07:25:54 -0800 X-Google-Sender-Auth: lRqA9wUu9fpz86qPwjSHkWnEDy8 Message-ID: Subject: Re: svn commit: r247710 - projects/calloutng/sys/kern From: mdf@FreeBSD.org To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: attilio@freebsd.org, Davide Italiano , src-committers@freebsd.org, svn-src-projects@freebsd.org, John Baldwin X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 15:25:56 -0000 On Tue, Mar 5, 2013 at 1:43 AM, Bruce Evans 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