From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: passing arg of `merge_face_heights' makes integer from pointer without a cast Date: Fri, 05 Nov 2004 10:01:47 -0500 Message-ID: References: <20041104211651.GA22409@fencepost> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1099667140 22863 80.91.229.6 (5 Nov 2004 15:05:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 5 Nov 2004 15:05:40 +0000 (UTC) Cc: schwab@suse.de, emacs-devel@gnu.org, miles@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 05 16:05:32 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CQ5ee-00050u-00 for ; Fri, 05 Nov 2004 16:05:32 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CQ5mp-0003vp-M6 for ged-emacs-devel@m.gmane.org; Fri, 05 Nov 2004 10:13:59 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CQ5lW-0003Ua-Vy for emacs-devel@gnu.org; Fri, 05 Nov 2004 10:12:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CQ5lT-0003TO-Nk for emacs-devel@gnu.org; Fri, 05 Nov 2004 10:12:36 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CQ5lS-0003Sb-Q3 for emacs-devel@gnu.org; Fri, 05 Nov 2004 10:12:35 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CQ5cz-0004PX-P1 for emacs-devel@gnu.org; Fri, 05 Nov 2004 10:03:49 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1CQ5b1-0003vD-0b; Fri, 05 Nov 2004 10:01:53 -0500 Original-To: Miles Bader In-reply-to: <20041104211651.GA22409@fencepost> (message from Miles Bader on Thu, 4 Nov 2004 16:16:51 -0500) 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: main.gmane.org gmane.emacs.devel:29462 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29462 > That structure looks like something for which cons cells would work, > so why not use cons cells? Because these structures are allocated on the stack -- they are very temporary and used extremely often. If they are allocated in the stack, then it should be easy to explicitly gcpro the Lisp_Object in each one. Just do that in the frame that allocates the struct. Doesn't that do the job this gcpro argument was intended to do? Here's another idea. How deep does this stack often get? Maybe just allocate a single vector and use it as a stack. If it ever isn't big enough, replace it with a vector twice as big. You can null out the whole vector at the end of face merging. Since this would be an ordinary Lisp vector, GC would handle it just fine, it just needs a staticpro.