The direction of malloc?

[Joseph S. Myers]

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