Date: Sun, 22 Dec 2013 03:15:24 +0100 From: Luca Barbato <lu_zero@...too.org> To: musl@...ts.openwall.com Subject: Re: Removing sbrk and brk 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
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.