From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r117464: Shrink Lisp_Sub_Char_Table by preferring C integers to Lisp_Objects. Date: Wed, 02 Jul 2014 10:30:34 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1404311465 26823 80.91.229.3 (2 Jul 2014 14:31:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Jul 2014 14:31:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 02 16:30:57 2014 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 1X2LYm-0000Xp-Gc for ged-emacs-devel@m.gmane.org; Wed, 02 Jul 2014 16:30:56 +0200 Original-Received: from localhost ([::1]:53487 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2LYm-0003ag-3q for ged-emacs-devel@m.gmane.org; Wed, 02 Jul 2014 10:30:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39338) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2LYa-0003Sx-Jp for emacs-devel@gnu.org; Wed, 02 Jul 2014 10:30:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2LYS-0002Dc-6D for emacs-devel@gnu.org; Wed, 02 Jul 2014 10:30:44 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:15137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2LYS-0002DX-1S for emacs-devel@gnu.org; Wed, 02 Jul 2014 10:30:36 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGAIDvNVNLd+D9/2dsb2JhbABZgwaDSr0vgw6BFxd0giYBAQRWIxALDiYHCxQYDSSIDNIZF456B4Q4BKMqhW+BaoFxgVsh X-IPAS-Result: ArYGAIDvNVNLd+D9/2dsb2JhbABZgwaDSr0vgw6BFxd0giYBAQRWIxALDiYHCxQYDSSIDNIZF456B4Q4BKMqhW+BaoFxgVsh X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="75695159" Original-Received: from 75-119-224-253.dsl.teksavvy.com (HELO pastel.home) ([75.119.224.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 02 Jul 2014 10:30:35 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id A5A9362F8B; Wed, 2 Jul 2014 10:30:34 -0400 (EDT) In-Reply-To: (Dmitry Antipov's message of "Wed, 02 Jul 2014 03:26:43 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:172848 Archived-At: > @@ -1465,10 +1466,10 @@ > contains 32 elements, and each element covers 128 characters. A > sub char-table of depth 3 contains 128 elements, and each element > is for one character. */ > - Lisp_Object depth; > + int depth; > /* Minimum character covered by the sub char-table. */ > - Lisp_Object min_char; > + int min_char; > /* Use set_sub_char_table_contents to set this. */ > Lisp_Object contents[FLEXIBLE_ARRAY_MEMBER]; > @@ -1539,12 +1540,16 @@ > const char *doc; > }; > -/* This is the number of slots that every char table must have. This > - counts the ordinary slots and the top, defalt, parent, and purpose > - slots. */ > -enum CHAR_TABLE_STANDARD_SLOTS > +enum char_table_specials > { > - CHAR_TABLE_STANDARD_SLOTS = PSEUDOVECSIZE (struct Lisp_Char_Table, extras) > + /* This is the number of slots that every char table must have. This > + counts the ordinary slots and the top, defalt, parent, and purpose > + slots. */ > + CHAR_TABLE_STANDARD_SLOTS = PSEUDOVECSIZE (struct Lisp_Char_Table, extras), > + > + /* This is an index of first Lisp_Object field in Lisp_Sub_Char_Table > + when the latter is treated as an ordinary Lisp_Vector. */ > + SUB_CHAR_TABLE_OFFSET = PSEUDOVECSIZE (struct Lisp_Sub_Char_Table, contents) > }; Are we sure this SUB_CHAR_TABLE_OFFSET exists? I don't see any reason why `contents' should necessarily be aligned on a multiple of Lisp_Objects. So, I think it's unsafe to cast your new "struct Lisp_Sub_Char_Table" to a "struct Lisp_Vector". Maybe it does work on current existing systems, but it's too fragile. Stefan