This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: The direction of malloc?
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Will Newton <will dot newton at linaro dot org>, Siddhesh Poyarekar <siddhesh at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Andreas Jaeger <aj at suse dot com>, Andreas Schwab <schwab at suse dot de>, Ondřej Bílka <neleai at seznam dot cz>
- Date: Mon, 16 Dec 2013 13:46:07 -0800 (PST)
- Subject: Re: The direction of malloc?
- Authentication-results: sourceware.org; auth=none
- References: <52A6A0DA dot 1080109 at redhat dot com> <CANu=Dmi32gwk-hQ3dDbj0d4_gs3FWqt02+NmveXH1p03Vm+Mfg at mail dot gmail dot com> <20131210111031 dot GH5048 at spoyarek dot pnq dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1312101654500 dot 15324 at digraph dot polyomino dot org dot uk> <CANu=Dmi5mr9z4P99LDB+8q6_1XcNraeofyScgFdwqOhZMBTTGQ at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1312101801170 dot 15324 at digraph dot polyomino dot org dot uk>
> 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.