This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The direction of malloc?


> The main purpose of malloc_get_state / malloc_set_state is for use by 
> emacs.  If emacs adopted a better approach I'd happily deprecate them - 
> turn them into compat symbols - but you still need to support them 
> indefinitely with existing emacs binaries, as a matter of binary 
> compatibility.  (Support could mean such binaries - binaries using the 
> malloc_set_state compat symbol - use a different copy of malloc in libc 
> from what all other binaries use, if necessary.)

(I believe I've mentioned this before when discussing the ppc32 ABI
situation.)  I'm pretty sure that the way Emacs uses malloc before dumping
is such that there's no significant amount of allocation done then (if any)
that will ever be freed later.  So for ABI compatibility it is probably
sufficient to have a malloc_set_state call from an old binary result in the
allocations made up to that point becoming unfreeable.  For correctness,
free in the new library would have to identify the given block as being
from the old regime and not do anything bad.  (Conceivably this could even
be done just with a compat symbol version for free, though probably there
are ways things will go wrong if the current-version free does bad things
when given a pointer from the old-version allocator.)  But it doesn't need
to be able to actually do anything worthwhile, like recover that memory for
future use, return it to the system, or ensure a double-free is detected.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]