Re: Dumper issue, revisited; invalid realloc/free

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 4 Feb 2015 17:17:04 -0500
> From: Rich Felker <dalias@libc.org>
> 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 <dalias@libc.org>
> > > 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.