Re: Removing sbrk and brk

[Szabolcs Nagy <nsz@port70.net>]

* Rich Felker <dalias@aerifal.cx> [2013-12-21 18:40:41 -0500]:
> As far as I can tell, the only remotely legitimate use for sbrk/brk is
> for applications to provide their own malloc implementation using it.

single-threaded static linked binaries may want to avoid pulling in
the entire malloc implementation with locks etc and use sbrk instead
(i know some plan9 tools did this), i guess that should work if only
async-signal-safe libc calls are used (those cannot use malloc or brk
internally), but i don't think this is common

sbrk(0) is a valid usage and i think that's common (eventhough it is
mostly useless)

> - making them always-fail
> - making the headers break use of them
> - completely removing the symbols
> 
> The latter options are in some ways preferable, since the failure
> would be caught at build-time and the program could be patched (or
> different configure options passed) to fix the incorrect sbrk usage.

i think there is a general problem of dangerous/broken/legacy interfaces

i would prefer a separate tool that can catch these at compile-/run-time
rather than fixing them in the libc (sbrk/brk are special because they
are almost always wrong while the other broken interfaces are possible
to use without invoking ub)

another solution is to split libc into libgood and libbad
(or mark the broken apis in some way to catch their usage easily)

...
> 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).

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