This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] malloc: Remove malloc_get_state, malloc_set_state
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Fri, 10 Jun 2016 10:42:38 -0700
- Subject: Re: [PATCH] malloc: Remove malloc_get_state, malloc_set_state
- Authentication-results: sourceware.org; auth=none
- References: <20160610093137 dot 7306E400F0E5F at oldenburg dot str dot redhat dot com>
Thanks for doing all this. Some comments:
+* The __malloc_get_state and __malloc_set_state functions have been removed
+ from the API. __malloc_get_state has been replaced with a stub
+ implementation. Existing undumped Emacs binaries will have to be
+ recompiled so that they do not use glibc malloc (or malloc heap dumping).
+ Existing installed Emacs binaries (after dumping) are not affected by this
The NEWS item should talk about the public API and so should refer to names
without leading underscores, and it'd be helpful to have a clearer discussion
about the backwards-compatibility constraints. Perhaps wording like the
The malloc_get_state and malloc_set_state functions have been removed.
Already-existing binaries that dynamically link to these functions will get a
hidden implementation in which malloc_get_state is a stub. As far as we know,
these functions are used only by GNU Emacs and this change will not adversely
affect already-built Emacs executables. Any undumped Emacs executables, which
normally exist only during an Emacs build, should be rebuilt by re-running
'configure; make' in the Emacs build tree.
+ return NULL;
Perhaps __malloc_get_state should set errno to ENOSYS? Emacs won't care about
errno, so this would merely be insurance in case someone else does care.
Perhaps the test program should be retained and should check that the hidden
__malloc_get_state function indeed returns NULL? Dunno how you'd test