From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4406 Path: news.gmane.org!not-for-mail From: Luca Barbato Newsgroups: gmane.linux.lib.musl.general Subject: Re: Removing sbrk and brk Date: Sun, 22 Dec 2013 19:21:58 +0100 Message-ID: <52B72DC6.3060201@gentoo.org> References: <20131221234041.GA13204@brightrain.aerifal.cx> <52B64B3C.6090909@gentoo.org> <52B7282C.6020606@pennware.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1387736509 5640 80.91.229.3 (22 Dec 2013 18:21:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Dec 2013 18:21:49 +0000 (UTC) To: Richard Pennington , musl@lists.openwall.com Original-X-From: musl-return-4410-gllmg-musl=m.gmane.org@lists.openwall.com Sun Dec 22 19:21:56 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Vunf2-0002Zk-Bn for gllmg-musl@plane.gmane.org; Sun, 22 Dec 2013 19:21:56 +0100 Original-Received: (qmail 11366 invoked by uid 550); 22 Dec 2013 18:21:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 11356 invoked from network); 22 Dec 2013 18:21:55 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <52B7282C.6020606@pennware.com> Xref: news.gmane.org gmane.linux.lib.musl.general:4406 Archived-At: 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 =)