From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs and Gnome Canvas Date: Sat, 17 Jul 2010 13:23:20 +0300 Message-ID: <83vd8ee7af.fsf@gnu.org> References: <4C3EE8D6.3020607@swipnet.se> <8339vlgcax.fsf@gnu.org> <87fwzkbzg8.fsf@telefonica.net> <877hkwag6y.fsf@stupidchicken.com> <877hkwbth6.fsf@telefonica.net> <83pqyofzdg.fsf@gnu.org> <8739vkbpq5.fsf@telefonica.net> <83oce8fwlq.fsf@gnu.org> <87tyo0a11p.fsf@telefonica.net> <83k4ovg7rn.fsf@gnu.org> <87630fa4j8.fsf@telefonica.net> <83d3unfo92.fsf@gnu.org> <87wrsv8l6u.fsf@telefonica.net> <83bpa7feta.fsf@gnu.org> <87zkxr6s34.fsf@telefonica.net> <56009CA1-80D6-43CC-BC46-42002D2B4498@mit.edu> <87r5j36kc4.fsf@telefonica.net> <83630efsl8.fsf@gnu.org> <831vb2fp8c.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: dough.gmane.org 1279362222 14868 80.91.229.12 (17 Jul 2010 10:23:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 17 Jul 2010 10:23:42 +0000 (UTC) Cc: ofv@wanadoo.es, emacs-devel@gnu.org To: Andreas Schwab Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 17 12:23:39 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Oa4YQ-0000ko-Es for ged-emacs-devel@m.gmane.org; Sat, 17 Jul 2010 12:23:34 +0200 Original-Received: from localhost ([127.0.0.1]:57630 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oa4YP-0005Ou-Iy for ged-emacs-devel@m.gmane.org; Sat, 17 Jul 2010 06:23:33 -0400 Original-Received: from [140.186.70.92] (port=52798 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oa4YG-0005O9-1l for emacs-devel@gnu.org; Sat, 17 Jul 2010 06:23:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oa4YF-0005R5-23 for emacs-devel@gnu.org; Sat, 17 Jul 2010 06:23:23 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:61132) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oa4YE-0005Qz-RG for emacs-devel@gnu.org; Sat, 17 Jul 2010 06:23:23 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0L5P00A00615AL00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 17 Jul 2010 13:23:21 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.61.30]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L5P008T066WFH40@a-mtaout22.012.net.il>; Sat, 17 Jul 2010 13:23:21 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:127505 Archived-At: > From: Andreas Schwab > Date: Sat, 17 Jul 2010 11:40:17 +0200 > Cc: ofv@wanadoo.es, emacs-devel@gnu.org >=20 > Eli Zaretskii writes: >=20 > > Can you really avoid having C++ objects that reference Emacs buff= ers > > and strings? >=20 > Just like you have to be careful not to use direct pointers into st= ring > and buffer space in C. Nothing new here. "Nothing new" for me and you, perhaps. But I'm not sure about =C3= =93scar. > > And on some platforms (although not on GNU/Linux, I think) malloc= is > > also replaced, so there's no "normal malloc space" per se. >=20 > ralloc always divides the allocated space into malloc areas (handed= to > malloc and friends) and relocatable blocks (handed to r_alloc and > friends). I'm quite sure I've bumped in the past into a bug triggered by a call to malloc from a library function which had nothing to do with relocatable blocks. The bug happened because that malloc call caused buffer text to be relocated. Maybe the implementation changed since then, though.