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: Potential GC-related problems in compose_chars_in_text Date: Mon, 19 Sep 2005 09:43:14 -0400 Message-ID: <8764sxyy63.fsf-monnier+emacs@gnu.org> References: <87k6hh2fe8.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1127137706 27204 80.91.229.2 (19 Sep 2005 13:48:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 19 Sep 2005 13:48:26 +0000 (UTC) Cc: storm@cua.dk, emacs-devel@gnu.org, handa@m17n.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 19 15:48:22 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EHLzG-0004Im-2p for ged-emacs-devel@m.gmane.org; Mon, 19 Sep 2005 15:47:14 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EHLzF-0007gk-KU for ged-emacs-devel@m.gmane.org; Mon, 19 Sep 2005 09:47:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EHLyq-0007cq-Vd for emacs-devel@gnu.org; Mon, 19 Sep 2005 09:46:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EHLym-0007aZ-98 for emacs-devel@gnu.org; Mon, 19 Sep 2005 09:46:47 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EHLyk-0007Z2-Nn for emacs-devel@gnu.org; Mon, 19 Sep 2005 09:46:42 -0400 Original-Received: from [209.226.175.54] (helo=tomts10-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EHLvU-0003MM-Si; Mon, 19 Sep 2005 09:43:21 -0400 Original-Received: from alfajor ([70.49.81.204]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050919134319.VVKG26102.tomts10-srv.bellnexxia.net@alfajor>; Mon, 19 Sep 2005 09:43:19 -0400 Original-Received: by alfajor (Postfix, from userid 1000) id 0C9F0D7828; Mon, 19 Sep 2005 09:43:15 -0400 (EDT) Original-To: rms@gnu.org In-Reply-To: (Richard M. Stallman's message of "Sat, 17 Sep 2005 09:39:06 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:43073 Archived-At: > Actually, it often happens that things like ENABLE_CHECKING add assert > statements in the macro expansion which causes the args to be used more > than once. > As far as I can see, ENABLE_CHECKING has no such effect anywhere. It does. See the definition of XSET: #define XSET(var, type, ptr) \ (eassert (XTYPE (ptr) == 0), /* Check alignment. */ \ (var) = ((EMACS_INT) (type)) | ((EMACS_INT) (ptr))) > And there is only one definition of SREF. Yes, currently SREF does not currently "suffer" from this problem, but it may become useful at some point in the future to add some kind of check on the second or of SREF. I have myself bumped into such problem when I try to add such checks in XINT (which currently doesn't check that its arg is indeed an integer). Stefan