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