Re: Removing sbrk and brk

[Luca Barbato <lu_zero@gentoo.org>]

On 22/12/13 18:58, Richard Pennington wrote:
> 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.
> 

Sounds like a plan =)