[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52B7282C.6020606@pennware.com>
Date: Sun, 22 Dec 2013 11:58:04 -0600
From: Richard Pennington <rich@...nware.com>
To: musl@...ts.openwall.com
CC: Luca Barbato <lu_zero@...too.org>
Subject: Re: Removing sbrk and brk
On 12/21/2013 08:15 PM, Luca Barbato wrote:
> On 22/12/13 00:40, Rich Felker wrote:
>> Finally, another alternative might be leaving sbrk/brk alone and
>> modifying malloc not to use the brk at all. This has been proposed
>> several times (well, supporting non-brk allocation has been proposed
>> anyway) to avoid spurious malloc failures when the brk cannot be
>> extended, and if we support that we might as well just drop brk
>> support in malloc (otherwise there's code with duplicate functionality
>> and thus more bloat). So this might actually be the best long-term
>> option. Switching malloc from using brk to PROT_NONE/mprotect (see the
>> above idea for brk emulation) would also make the malloc
>> implementation more portable to systems with no concept of brk.
>> However this option would definitely be a post-1.0 development
>> direction, and not something we could do right away (of course I'd
>> probably hold off until after 1.0 for any of these changes since
>> they're fairly invasive, except possibly the idea of making sbrk
>> always-fail).
> I'd add compile time and runtime warnings and plan for post-1.0
>
> lu
The latest OS X Mavericks has sbrk() marked as deprecated and clang
issues a warning for using it.
-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.
