Subject: sbrk() semantics ....
To: None <mouse@Collatz.McRCIM.McGill.EDU>
From: Gordon W. Ross <firstname.lastname@example.org>
Date: 03/13/1995 08:29:46
> Date: Mon, 13 Mar 1995 07:48:17 -0500
> From: der Mouse <email@example.com>
> [re sbrk/brk going away]
> Speaking as someone who's written software that uses sbrk(), the first
> two reasons that come to mind are (a) to allocate large chunks of
> memory that will never be freed, without the space wastage malloc()
> often produces, and (b) for anything that needs a memory allocator more
> sophisticated than malloc().
> [...] But IMO _some_ mechanism should be exported for user-land to
> get memory without the time and space overheads imposed by malloc().
There is a way: (at least for SunOS, NetBSD, SysVr4, ...)
(The trick: mmap /dev/zero with MAP_PRIVATE)
* Request BYTES of new memory from the OS.
* It will be cleared to zero and page-aligned.
* (You don't really get it until you touch it! 8^)
fd = open("/dev/zero", O_RDONLY, 0);
if (fd < 0)
addr = mmap(NULL, bytes, PROT_READ|PROT_WRITE,
MAP_PRIVATE, fd, 0);