This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: malloc: performance improvements and bugfixes
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: "GNU C. Library" <libc-alpha at sourceware dot org>
- Date: Tue, 26 Jan 2016 14:18:43 -0800
- Subject: Re: malloc: performance improvements and bugfixes
- Authentication-results: sourceware.org; auth=none
- References: <1453767942-19369-1-git-send-email-joern at purestorage dot com> <56A6C2E4 dot 7050508 at cs dot ucla dot edu> <1453841413 dot 18407 dot 7 dot camel at oc7878010663> <56A7E7E2 dot 8090604 at redhat dot com> <56A7EA47 dot 1000908 at cs dot ucla dot edu> <56A7EBCB dot 7010408 at redhat dot com>
On 01/26/2016 01:57 PM, Florian Weimer wrote:
One change you can make*today* is to include <malloc.h> in src/emacs.c
(conditionally for dlmalloc), and not just the autoconf test case.
Emacs has included <malloc.h> for decades, in src/alloca.c, so this part
is already done.
you will actually see new deprecation warnings as they appear in
the header file.
In practice this kind of deprecation warnings tends to be more trouble
than it's worth. We already know about the compatibility issues, and
don't need the deprecation warnings to remind us. The warnings will
probably cause needless work by users who will not understand the
details and who will send us low-value bug reports.
Come to think of it, how can we shut the deprecation warnings off? There
should be an easy way for Emacs to do that.