From owner-svn-src-all@FreeBSD.ORG Tue May 19 14:11:33 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4167AFD8 for ; Tue, 19 May 2015 14:11:33 +0000 (UTC) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) by mx1.freebsd.org (Postfix) with SMTP id 04C191044 for ; Tue, 19 May 2015 14:11:32 +0000 (UTC) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 19 May 2015 14:11:34 +0000 (UTC) Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t4JEBL7E016811; Tue, 19 May 2015 08:11:21 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1432044681.91685.77.camel@freebsd.org> Subject: Re: svn commit: r283088 - head/sys/ddb From: Ian Lepore To: Pedro Giffuni Cc: Bruce Evans , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Tue, 19 May 2015 08:11:21 -0600 In-Reply-To: <406A7AE3-1891-4B2C-B917-14C150EBBAB5@FreeBSD.org> References: <201505182227.t4IMRljx078812@svn.freebsd.org> <20150519113755.U1840@besplex.bde.org> <406A7AE3-1891-4B2C-B917-14C150EBBAB5@FreeBSD.org> Content-Type: text/plain; charset="iso-8859-13" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 14:11:33 -0000 On Mon, 2015-05-18 at 22:49 -0500, Pedro Giffuni wrote: > > Il giorno 18/mag/2015, alle ore 20:48, Bruce Evans ha scritto: > > > > On Mon, 18 May 2015, Pedro F. Giffuni wrote: > > > >> Log: > >> ddb: stop boolean screaming. > >> > >> TRUE --> true > >> FALSE--> false > >> > >> Hinted by: NetBSD > > > > This is not just churn to a style regression, but a type mismatch. > > > > It is an attempt to reduce differences with NetBSD. > > One of the complaints of hear from newcomers to the ddb code is that > the format is old-fashioned (it still had pre-ANSI headers not long ago) > and unmaintained. > > >> Modified: head/sys/ddb/db_break.c > >> ============================================================================== > >> --- head/sys/ddb/db_break.c Mon May 18 22:14:06 2015 (r283087) > >> +++ head/sys/ddb/db_break.c Mon May 18 22:27:46 2015 (r283088) > >> @@ -155,12 +155,12 @@ db_find_breakpoint_here(db_addr_t addr) > >> return db_find_breakpoint(db_map_addr(addr), addr); > >> } > >> > >> -static boolean_t db_breakpoints_inserted = TRUE; > >> +static boolean_t db_breakpoints_inserted = true; > > > > This code hasn't been churned to use the boolean type. It still uses > > boolean_t, which is plain int. TRUE and FALSE go with this type. true > > and false go with the boolean type. This probably makes no difference, > > because TRUE happens to be implemented with the same value as true and > > there are lots of implicit versions between the types. > > > > Yes, I noticed the return types are still ints. It doesn˙t look difficult > to convert it to use a real boolean type. In any case, I would prefer to go > forward (using bool) instead of reverting this change. > Yes, please do. Pedanticism aside, boolean types are extremely valuable because they document the intended use of the data. IMO the value in that far outweighs arguments about spelling and conversions and other whinging about things that work just fine. To sum it up, "int" is one of the vaguest things you can say in C, and "boolean" (in any reasonable spelling variation) is one of the clearest. -- Ian > > The boolean type is almost useless since C's type system is too weak to > > distinguish between plain int used as a boolean and pure boolean. If > > it were stronger, then it would complain about all the implicit conversions > > between int and boolean, and the boolean type would be harder to use for > > other reasons. > > > > And I would like that to happen, but it would probably break a lot of legacy code. > I thought boolean_t was a transition type. > > > Pedro. > > >