Date: Thu, 2 Jan 2014 17:03:02 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Removing sbrk and brk On Sun, Dec 22, 2013 at 11:46:09PM -0500, Rich Felker wrote: > > so the options in increasing effort are > > > > 1) leave it as is > > 2) completely remove sbrk/brk > > 3) always fail (except for sbrk(0)) > > 4) emulate with mmap+mprotect > > 5) malloc without brk > > > > i like 1) or 3) for 1.0 and 5) for post-1.0 > > I agree mostly. Option 5 would be ideal, but it depends on determining > whether there would be detrimental affects on performance. Even if > there are, however, it may be acceptable since I eventually want to > drop the madvise-based approach to returning memory to the kernel, > which doesn't relinquish any commit charge, and replace it with > PROT_NONE... > > For now though it seems we're trying to decide between options 1 and > 3. If we go for option 1, we should fix the integer overflow/wrapping > issue in sbrk you reported on irc.. OK, I'm modifying sbrk so sbrk(0) returns the current brk and sbrk(nonzero) returns (void*)-1 with errno set to ENOMEM (option 3 above). This should help us catch any programs attempting to use sbrk for memory management and get them fixed rather than dealing with hideous memory-corruption errors that are hard to track down, and we'll have some time to track them down between now and 1.0. sbrk may be re-added sometime after 1.0 if malloc is changed to no longer use the brk (option 5 above). 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.