On Mon, Aug 17, 2020 at 2:45 PM Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
On Mon, 17 Aug 2020 at 21:34, Paul Winalski <paul.winalski@gmail.com> wrote:
>
> On 8/17/20, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> >
> > Yes, it only uses sbrk(). One consequence I think is that sbrk()
> > expands the process memory without invalidating existing use of memory
> > - so the code is able to periodically expand heap while retaining all
> > existing allocations.
>
> If everyone does that, you can call other people's code without fear
> of stepping on their memory when you allocate memory in your code.
> Using a negative value to decrease the break is more problematic.
> malloc() usually uses sbrk() to extend its heap.
>
> When we ported DEC's GEM compilation system to Unix, I used sbrk() to
> extend memory and built my own multiple heap allocation scheme on top
> of that.  I could have used malloc() to allocate the heap chunks, but
> there was no point.  Might as well cut out the middleman.
>

Unfortunately sbrk() is not portable (I am building on Windows with
MSVC too) and as far as I know was even removed from POSIX.

From Wikipedia:
sbrk and brk are considered legacy even by 1997 standards (Single UNIX
Specification v2 or POSIX.1-1998).[5] They were removed in
POSIX.1-2001.[6]

gnu emacs was the last big user of sbrk. It was one of the few programs that didn't run on FreeBSD/arm64 which never had sbrk() because it wasn't possible to sanely implement. It wasn't until recently that gnu emacs fixed things to not use sbrk()...

Warner