Date: Sun, 22 Dec 2013 19:21:58 +0100 From: Luca Barbato <lu_zero@...too.org> To: Richard Pennington <rich@...nware.com>, musl@...ts.openwall.com Subject: Re: Removing sbrk and brk 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 =)
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.