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: Feature freeze on October 1 Date: Thu, 27 Sep 2012 08:57:23 -0400 Message-ID: References: <878vbval16.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1348750669 11783 80.91.229.3 (27 Sep 2012 12:57:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Sep 2012 12:57:49 +0000 (UTC) Cc: eliz@gnu.org, cyd@gnu.org, emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 27 14:57:54 2012 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 1THDf7-00077z-Nu for ged-emacs-devel@m.gmane.org; Thu, 27 Sep 2012 14:57:53 +0200 Original-Received: from localhost ([::1]:37501 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THDf2-0001fz-JF for ged-emacs-devel@m.gmane.org; Thu, 27 Sep 2012 08:57:48 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60358) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THDes-0001fS-NA for emacs-devel@gnu.org; Thu, 27 Sep 2012 08:57:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THDer-0001HG-Sx for emacs-devel@gnu.org; Thu, 27 Sep 2012 08:57:38 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:18936) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THDeg-00015M-N0; Thu, 27 Sep 2012 08:57:26 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09FxLT4/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLNBIUGA0kiBwFugmLG4UpA6MzgViDBYE6 X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="200109150" Original-Received: from 69-196-180-248.dsl.teksavvy.com (HELO pastel.home) ([69.196.180.248]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 27 Sep 2012 08:57:24 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 6C6B45938D; Thu, 27 Sep 2012 08:57:23 -0400 (EDT) In-Reply-To: <878vbval16.fsf@gnu.org> (Kenichi Handa's message of "Thu, 27 Sep 2012 18:10:29 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:153629 Archived-At: >> > Your memory is fine. The workaround code is in ralloc.c and in >> > maybe_unify_char. But since we still call maybe_unify_char in >> > decode_char, I don't think we can remove those workarounds yet, can >> > we? >> Are there calls to decode_char which aren't prepared to run Elisp code? > maybe_unify_char doesn't run Elisp code but allocates a Lisp > vector and a Lisp chartable via load_charset. Oh, indeed, I see it should not be able to run arbitrary Elisp, so the damage is a bit more limited. > And I'm not sure that all calls to decode_char are prepared > to buffer/string relocation. String relocation only happens during GC, which normally only happens during Elisp evaluation, so that shouldn't be an issue. But, yes, it seems that ccl.c and maybe coding.c both have uses of decode_char where buffer relocation can cause problems (CODING_DECODE_CHAR seems to try and handle it explicitly, but I'm not sure it's sufficient). Stefan