From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Intervals crash Date: Mon, 27 Sep 2010 11:02:02 +0200 Organization: Organization?!? Message-ID: <87y6anblv9.fsf@lola.goethe.zz> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1285578817 3451 80.91.229.12 (27 Sep 2010 09:13:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 27 Sep 2010 09:13:37 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 27 11:13:36 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 1P09mB-0006DJ-RB for ged-emacs-devel@m.gmane.org; Mon, 27 Sep 2010 11:13:36 +0200 Original-Received: from localhost ([127.0.0.1]:35457 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P09m7-0005kg-1q for ged-emacs-devel@m.gmane.org; Mon, 27 Sep 2010 05:13:31 -0400 Original-Received: from [140.186.70.92] (port=59461 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P09k9-0004oT-1Y for emacs-devel@gnu.org; Mon, 27 Sep 2010 05:11:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1P09bA-0002LN-Ig for emacs-devel@gnu.org; Mon, 27 Sep 2010 05:02:14 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:43580) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P09bA-0002LI-6O for emacs-devel@gnu.org; Mon, 27 Sep 2010 05:02:12 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P09b9-0002bO-6T for emacs-devel@gnu.org; Mon, 27 Sep 2010 11:02:11 +0200 Original-Received: from p508eb907.dip.t-dialin.net ([80.142.185.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Sep 2010 11:02:11 +0200 Original-Received: from dak by p508eb907.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Sep 2010 11:02:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 55 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: p508eb907.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:maUD9SQrnfx0wfM0E6CfwOrEKag= 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:130981 Archived-At: Eli Zaretskii writes: >> From: Jan Djärv >> Cc: emacs-devel@gnu.org >> >> There are only 77 places where EMACS_UINT occurs in the Emacs >> sources. > > 73, to be exact. The rest are #define's and #ifndef's related to the > definition of EMACS_UINT itself; they don't count. #define XUINT > should probably also be excluded, as it doesn't really "use" > EMACS_UINT. > >> Most of them are casts to and from pointers, and some are sizes >> (like in Lisp_Vector). It would not be a big job to get rid of them >> if that is what we want. > > 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? > I'm not sure we want to make that assumption, though, since lisp.h > does allow for external definition of EMACS_UINT by some s/*.h or > m/*.h file. > > 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? > . the value is a pointer that is subject to bitwise operations Why would a pointer be put into an EMACS_UINT? > . 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? If we use this as a Lisp integer, we won't be able to make use of the full "unsigned" size. If we don't use this as a Lisp integer, why use EMACS_UINT in the first place? -- David Kastrup