From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: [patch] mem_node shrink Date: Wed, 21 Nov 2007 21:26:35 -0500 Message-ID: References: <474168CE.5020502@yandex.ru> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1195698412 2473 80.91.229.12 (22 Nov 2007 02:26:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Nov 2007 02:26:52 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 22 03:26:57 2007 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.50) id 1Iv1mK-0004v5-TG for ged-emacs-devel@m.gmane.org; Thu, 22 Nov 2007 03:26:57 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iv1m6-0007RZ-Ls for ged-emacs-devel@m.gmane.org; Wed, 21 Nov 2007 21:26:42 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Iv1m1-0007NO-Uz for emacs-devel@gnu.org; Wed, 21 Nov 2007 21:26:37 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Iv1m1-0007MJ-Fx for emacs-devel@gnu.org; Wed, 21 Nov 2007 21:26:37 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iv1m1-0007Ly-4z for emacs-devel@gnu.org; Wed, 21 Nov 2007 21:26:37 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Iv1m0-0000NC-L6 for emacs-devel@gnu.org; Wed, 21 Nov 2007 21:26:36 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1Iv1lz-0003eG-V9; Wed, 21 Nov 2007 21:26:36 -0500 In-reply-to: <474168CE.5020502@yandex.ru> (message from Dmitry Antipov on Mon, 19 Nov 2007 13:43:26 +0300) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:83821 Archived-At: The idea looks like an improvement. I think there needs to be a comment explaining that the widths of these fields are supposed to add up to the same as an EMACS_INT. And is EMACS_INT the right thing? EMACS_INT is `long' in some cases. Should it be plain `int' instead? Should it be a type that's as wide as a pointer or as size_t? Should the size value be measured in units of Lisp_Object instead of bytes? + if (size > MOST_POSITIVE_FIXNUM) + abort (); +#endif That's not reliably the correct test. It happens to be right, at present, because the width of the field is BITS_PER_EMACS_INT - 4, and it is unsigned, so it has the same number of bits as a positive Lisp integer. But that is just coincidence. So I think MOST_POSITIVE_FIXNUM should be replaced with something guaranteed to be right. Define a constant to serve as the width of that field, and use the same constant here in something like -((-1) << MEM_NODE_SIZE_WIDTH). /* Can't handle zero size regions in the red-black tree. */ - mem_insert (value, (char *) value + max (size, 1), MEM_TYPE_NON_LISP); + mem_insert (value, max (size, 1), MEM_TYPE_NON_LISP); Wouldn't it be cleaner for mem_insert to do max (..., 1) ?