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);
}