Subject: sbrk() semantics ....
To: None <mouse@Collatz.McRCIM.McGill.EDU>
From: Gordon W. Ross <gwr@mc.com>
List: tech-kern
Date: 03/13/1995 08:29:46
> Date: Mon, 13 Mar 1995 07:48:17 -0500
> From: der Mouse <mouse@collatz.mcrcim.mcgill.edu>
> [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)
#include <sys/fcntl.h>
#include <sys/mman.h>
/*
* 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^)
*/
char *get_mem(bytes)
int bytes;
{
int fd;
char *addr;
fd = open("/dev/zero", O_RDONLY, 0);
if (fd < 0)
return (NULL);
addr = mmap(NULL, bytes, PROT_READ|PROT_WRITE,
MAP_PRIVATE, fd, 0);
close(fd);
return(addr);
}