From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.devel Subject: Re: Potential GC-related problems in compose_chars_in_text Date: Wed, 14 Sep 2005 22:41:13 -0400 Message-ID: References: Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1126753731 21215 80.91.229.2 (15 Sep 2005 03:08:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 15 Sep 2005 03:08:51 +0000 (UTC) Cc: storm@cua.dk, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 15 05:08:43 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EFk71-0004G5-Jm for ged-emacs-devel@m.gmane.org; Thu, 15 Sep 2005 05:08:35 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EFk70-0003V0-Vf for ged-emacs-devel@m.gmane.org; Wed, 14 Sep 2005 23:08:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EFk4O-000214-A1 for emacs-devel@gnu.org; Wed, 14 Sep 2005 23:05:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EFk4M-000207-KF for emacs-devel@gnu.org; Wed, 14 Sep 2005 23:05:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EFk0W-0000ZN-1o for emacs-devel@gnu.org; Wed, 14 Sep 2005 23:01:52 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EFjgZ-0006Se-1X for emacs-devel@gnu.org; Wed, 14 Sep 2005 22:41:15 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1EFjgX-0000gd-7I; Wed, 14 Sep 2005 22:41:13 -0400 Original-To: Kenichi Handa In-reply-to: (message from Kenichi Handa on Wed, 14 Sep 2005 16:29:16 +0900) 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:42942 Archived-At: > I think that the cleanest thing to do, in loops that don't need to be > as fast as possible, is avoid saving addresses of string data at all. I agree. But, I think display_mode_element is the place that have to be as fast as possible. I would think that it doesn't take up very much of Emacs cpu time, and that a small slowdown there would be insignificant. That function calls subroutines that do a lot of work. Looking at the new code, I think it is correct. It is correct because the code consists of many alternatives, and each one does only a single nontrivial thing and then gets to the end, where lisp_string and this are updated. But it seems a bit fragile to me. What if some branch is later changed to do two things that could relocate? Then it would have a bug again. So I think I will still put in the change I made. The reason I worry about the patch you made is that it depends on knowing exactly where the relocation might occur.