From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Intervals crash Date: Mon, 27 Sep 2010 07:02:54 -0400 Message-ID: References: <87aan82uar.fsf@stupidchicken.com> <83bp7ouw2u.fsf@gnu.org> <87bp7n3c19.fsf@uwakimon.sk.tsukuba.ac.jp> <83iq1vtv3y.fsf@gnu.org> <87wrqb1q2b.fsf@uwakimon.sk.tsukuba.ac.jp> <83fwwztq4e.fsf@gnu.org> <87sk0x28pr.fsf@uwakimon.sk.tsukuba.ac.jp> <83y6aprehh.fsf@gnu.org> <87hbhd1wn4.fsf@uwakimon.sk.tsukuba.ac.jp> <83vd5tqxyp.fsf@gnu.org> <87eicg1wl5.fsf@uwakimon.sk.tsukuba.ac.jp> <878w2o1fa3.fsf@catnip.gol.com> <87y6aneqhs.fsf@uwakimon.sk.tsukuba.ac.jp> <87fwwvd6aq.fsf@lola.goethe.zz> <4CA04AFB.5060302@swipnet.se> <87y6anblv9.fsf@lola.goethe.zz> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1285585388 32383 80.91.229.12 (27 Sep 2010 11:03:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 27 Sep 2010 11:03:08 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 27 13:03:07 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1P0BUA-0000Y5-6D for ged-emacs-devel@m.gmane.org; Mon, 27 Sep 2010 13:03:06 +0200 Original-Received: from localhost ([127.0.0.1]:46316 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P0BU9-0000P1-2N for ged-emacs-devel@m.gmane.org; Mon, 27 Sep 2010 07:03:05 -0400 Original-Received: from [140.186.70.92] (port=34555 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P0BU0-0000Np-Bo for emacs-devel@gnu.org; Mon, 27 Sep 2010 07:02:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1P0BTz-0003P0-0z for emacs-devel@gnu.org; Mon, 27 Sep 2010 07:02:56 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:36251) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P0BTy-0003Ow-Vi for emacs-devel@gnu.org; Mon, 27 Sep 2010 07:02:54 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1P0BTy-0007Hy-Gu; Mon, 27 Sep 2010 07:02:54 -0400 In-reply-to: <87y6anblv9.fsf@lola.goethe.zz> (message from David Kastrup on Mon, 27 Sep 2010 11:02:02 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:130989 Archived-At: > From: David Kastrup > Date: Mon, 27 Sep 2010 11:02:02 +0200 > > > We can get rid of almost all of them, if we believe that size_t and > > EMACS_UINT are always of the same size. > > Why wouldn't we be using size_t when we needed something of size size_t? We do, as a matter of habit. What I meant was to use size_t where we now use EMACS_UINT, because almost all of those places have nothing to do with Emacs integers. We simply use EMACS_UINT as a portable unsigned data type large enough to accommodate both size_t and a pointer. > > In any case, I think we cannot get rid of using an unsigned data type > > in most of the 70+ places we do now, because of one or more of the > > following reasons: > > > > . the value is a bit mask or a bit map > > We have the assumption of two's complement arithmetic hardwired in a lot > of other places. So bit operations should work on signed numbers > reasonably well. Possible exception are right shifts when indeed the > full range of an EMACS_UINT over an EMACS_INT is being employed, but > then the number will not convert into an Elisp integer readily anyhow, > so why use EMACS_UINT at all? I obviously didn't make myself clear: these are _not_ reasons to use EMACS_UINT, these are reasons why we sometimes need an unsigned integer data type. >> > . the value is a pointer that is subject to bitwise operations > > Why would a pointer be put into an EMACS_UINT? Again, not into EMACS_UINT, but rather into an unsigned data type. The reason is, of course, that almost every Lisp_Object is a pointer in disguise, and alloc.c was why I put this reason in the list. > > . the value is an unsigned data type forced by external hardware or > > software API > > Again, why an EMACS_UINT rather than the appropriate unsigned data type > forced by the external hardware? See above, this isn't about EMACS_UINT. We will need some unsigned data type that is portable between 32- and 64-bit architectures. > If we use this as a Lisp integer We don't, and I didn't say we should. I was talking about unsigned data types that we would need even if we get rid of EMACS_UINT.