Re: Removing sbrk and brk

[Rich Felker <dalias@aerifal.cx>]

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