From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.emacs.devel Subject: Re: Dumper issue, revisited; invalid realloc/free Date: Wed, 4 Feb 2015 17:17:04 -0500 Message-ID: <20150204221704.GD23507@brightrain.aerifal.cx> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1423088247 22798 80.91.229.3 (4 Feb 2015 22:17:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Feb 2015 22:17:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 04 23:17:27 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 1YJ8GD-0007KO-FJ for ged-emacs-devel@m.gmane.org; Wed, 04 Feb 2015 23:17:25 +0100 Original-Received: from localhost ([::1]:39127 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ8GC-0001h0-U2 for ged-emacs-devel@m.gmane.org; Wed, 04 Feb 2015 17:17:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35788) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ8Fy-0001gZ-5C for emacs-devel@gnu.org; Wed, 04 Feb 2015 17:17:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJ8Fx-0001Ql-7A for emacs-devel@gnu.org; Wed, 04 Feb 2015 17:17:10 -0500 Original-Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:51463 helo=brightrain.aerifal.cx) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ8Ft-0001Q9-JS; Wed, 04 Feb 2015 17:17:05 -0500 Original-Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1YJ8Fs-0004ZG-00; Wed, 04 Feb 2015 22:17:04 +0000 Content-Disposition: inline In-Reply-To: <83egq5fm1c.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 216.12.86.13 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:182411 Archived-At: 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. (This is actually a practical consideration, as we have someone working on a development environment that brings musl to Windows with the intent of replacing both cygwin and mingw with something that satisfies the major usage cases for both and offers various advantages.) Rich