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: Dumper issue, revisited; invalid realloc/free Date: Thu, 05 Feb 2015 05:42:17 +0200 Message-ID: <83d25pf2hy.fsf@gnu.org> References: <20150204175709.GX23507@brightrain.aerifal.cx> <83oap9fppc.fsf@gnu.org> <20150204193732.GZ23507@brightrain.aerifal.cx> <83k2zxfomm.fsf@gnu.org> <20150204200842.GC23507@brightrain.aerifal.cx> <83egq5fm1c.fsf@gnu.org> <20150204221704.GD23507@brightrain.aerifal.cx> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1423107756 23462 80.91.229.3 (5 Feb 2015 03:42:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Feb 2015 03:42:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Rich Felker Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 05 04:42:36 2015 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 1YJDKt-0003Fl-MJ for ged-emacs-devel@m.gmane.org; Thu, 05 Feb 2015 04:42:35 +0100 Original-Received: from localhost ([::1]:39856 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJDKs-0003xp-QY for ged-emacs-devel@m.gmane.org; Wed, 04 Feb 2015 22:42:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35302) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJDKq-0003xk-57 for emacs-devel@gnu.org; Wed, 04 Feb 2015 22:42:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJDKj-0002VH-8L for emacs-devel@gnu.org; Wed, 04 Feb 2015 22:42:32 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:36270) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJDKj-0002Uz-0v for emacs-devel@gnu.org; Wed, 04 Feb 2015 22:42:25 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NJA00H004VBKN00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Thu, 05 Feb 2015 05:42:23 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJA00HCY4YNKI00@a-mtaout23.012.net.il>; Thu, 05 Feb 2015 05:42:23 +0200 (IST) In-reply-to: <20150204221704.GD23507@brightrain.aerifal.cx> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:182424 Archived-At: > Date: Wed, 4 Feb 2015 17:17:04 -0500 > From: Rich Felker > Cc: emacs-devel@gnu.org > > On Wed, Feb 04, 2015 at 10:40:15PM +0200, Eli Zaretskii wrote: > > > Date: Wed, 4 Feb 2015 15:08:42 -0500 > > > From: Rich Felker > > > Cc: emacs-devel@gnu.org > > > > > > Upon checking master, w32heap.c is not using the system malloc. It's > > > its own implementation of the malloc API written on top of the Win32 > > > HeapAlloc API. > > > > System malloc on Windows is a thin wrapper around HeapAlloc, so we are > > actually using system malloc. There are good reasons why we call > > HeapAlloc directly, but they are immaterial for the purposes of this > > discussion. > > Yes, but from my standpoint it's conceptually very different -- as > written, it's depending on interposing its own definition of malloc > and would not work, for example, on a windows runtime that uses a > malloc not based on HeapAlloc. How is it different? You could make malloc a function pointer, and point it to one implementation at dump time, and to another after dumping. The main point here, and the one I thought was important for you, is that gmalloc is not used, i.e. the code does not depend on the internals of the malloc implementation. This condition is satisfied by using HeapAlloc.