From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Booleans Date: Sun, 15 Dec 2013 15:03:50 -0800 Organization: UCLA Computer Science Department Message-ID: <52AE3556.6080704@cs.ucla.edu> References: <83vbyqdncv.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1387148656 28085 80.91.229.3 (15 Dec 2013 23:04:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Dec 2013 23:04:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 16 00:04:20 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VsKjT-00013o-RZ for ged-emacs-devel@m.gmane.org; Mon, 16 Dec 2013 00:04:19 +0100 Original-Received: from localhost ([::1]:52780 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsKjT-0002ZQ-F5 for ged-emacs-devel@m.gmane.org; Sun, 15 Dec 2013 18:04:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53412) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsKjI-0002Rn-4k for emacs-devel@gnu.org; Sun, 15 Dec 2013 18:04:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VsKjA-0004kT-Qq for emacs-devel@gnu.org; Sun, 15 Dec 2013 18:04:08 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:40443) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsKj2-0004jX-Vt; Sun, 15 Dec 2013 18:03:53 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 9B2B739E8100; Sun, 15 Dec 2013 15:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppV3Ts-vqlSK; Sun, 15 Dec 2013 15:03:51 -0800 (PST) Original-Received: from [192.168.1.9] (pool-108-0-233-62.lsanca.fios.verizon.net [108.0.233.62]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 0ABDB39E80F8; Sun, 15 Dec 2013 15:03:51 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <83vbyqdncv.fsf@gnu.org> X-Enigmail-Version: 1.6 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:166446 Archived-At: Eli Zaretskii wrote: > I'm not sure I understand why we want such a wholesale > replacement of 0/1 with false/true. It's no big deal and we could easily change it back if desired. I did it primarily because Stefan suggested that I do so, while changing int to bool etc. > why is it a good idea to convert everything, including bitfields (which > required introduction of a new non-standard typedef), into booleans? If a value is a boolean, it typically makes things easer on the reader, the debugger, etc. to know that it's a boolean and not an integer, so that one needn't worry about values other than 0 and 1. bool_bf is a response to trunk bzr 115272, which used 'bool inhibit_shrinking : 1;'. This is not portable to pre-C99 platforms. I temporarily fixed that by changing 'bool' by 'unsigned' in trunk bzr 115280, but for maintainability 'bool' is indeed better, and 'bool_bf' attempts to support this while still maintaining portability to pre-C99 platforms. If we could assume C99 or later, we could get rid of bool_bf and just use bool. I'm thinking of proposing such an assumption for after the next release. This would allow us to use some other C99 features, such as declarations after statements, which would make Emacs easier to maintain. > should have been a separate commit, as > it is not a mechanical replacement, far from it. It was a judgment call. Perhaps I should have separated it out, though it's no big deal. It was a case of an int value being used as a boolean with values 0 and -1. > -#if 0 > +#if false > > ... I'm afraid I don't see the point I tried to be reasonably systematic in replacing uses of 0 and 1 as booleans in the set of files that I was looking at; this included the use of booleans in preprocessor expressions. It would be an odd style to use '0' for false preprocessor expressions, while using 'false' for false expressions everywhere else.