[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140310165349.GH184@brightrain.aerifal.cx>
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.
