This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The direction of malloc?

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]