This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: The direction of malloc?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, Andreas Jaeger <aj at suse dot com>, Andreas Schwab <schwab at suse dot de>, OndÅej BÃlka <neleai at seznam dot cz>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Tue, 10 Dec 2013 16:49:40 +0000
- Subject: Re: The direction of malloc?
- Authentication-results: sourceware.org; auth=none
- References: <52A6A0DA dot 1080109 at redhat dot com>
On Tue, 10 Dec 2013, Carlos O'Donell wrote:
> We should accept these patches without the restrictions we previously
> placed on the malloc implementation. We should use GNU formatting to
> make the code match all of our other styles. In effect we should
> own the copy of ptmalloc2 we started with and change it into the
> implementation that we think our users need.
Agreed as regards malloc, fdlibm, RPC, miscellaneous code from various
versions of BSD and probably a few other bits of non-FSF-assigned code
taken from a range of upstream sources a long time ago - I don't think any
of those are at all likely to be merged from upstream. Quite likely also
for libidn (non-FSF-assigned, upstream now LGPLv3).
I hope the gettext and GMP code *will* get merged to and from upstream
again in future (with the glibc versions remaining LGPLv2.1+, but other
differences being eliminated if possible). But I don't think that should
stop us including that code in global cleanups, given it's also GNU code
meant to be following GNU coding style. I don't know about the resolver
code from BIND, a substantial body of code that I think *is* maintained
upstream of glibc but was last updated from upstream in glibc 2.2
(according to the NEWS file, anyway). The resolver code is the only code
for which I think merge difficulty might be a reason to avoid some
cleanups or other changes.
--
Joseph S. Myers
joseph@codesourcery.com