Date: Mon, 10 Mar 2014 12:53:49 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Re: Release schedule & tasks for 1.0 On Mon, Mar 10, 2014 at 09:50:54AM +0000, juris wrote: > On Mon, 10 Mar 2014 03:04:11 -0400 > Rich Felker <dalias@...ifal.cx> wrote: > > > If anyone has outstanding bugs that can be fixed quickly and > > non-invasively (low risk from making changes) please [re-]report them > > in this thread. > > Not exactly a bug fix, but does something like this qualify for 1.0 inclusion? > Lifted it from http://article.gmane.org/gmane.linux.lib.musl.general/1255/ and prettied up a little. No, it's well outside the scope of what should be done during feature freeze. Aside from the namespace issues, the big concern is that adding new nonstandard interfaces like this could cause programs to start using them (via autoconf detection) and break things if the implementation of the new function does not behave exactly as expected. Aside from the freeze issue, this is one function I'm hesitant to add at all. Adding it is making a contract to preserve it permanently, and that in turn puts constraints on the malloc implementation. Right now it's practical to obtain the usable size of a chunk, but that doesn't mean it would remain practical under all reasonable redesigns of the internals. This function has also historically been buggy in glibc (it reports as usable parts of the region used for overflow/corruption detection, then realloc/free later aborts when the application has used this region). This was only fixed sometime in the last year or two, so programs using it are probably already buggy on most deployed glibc versions and should just be fixed... Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.