Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!sri-unix!hplabs!pyramid!amdahl!oliveb!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: brk's zero-fill behavior on VAXen
Message-ID: <8833@sun.uucp>
Date: Mon, 3-Nov-86 03:24:25 EST
Article-I.D.: sun.8833
Posted: Mon Nov  3 03:24:25 1986
Date-Received: Tue, 4-Nov-86 05:08:42 EST
References: <7208@elsie.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 21

> In section 2 of the UNIX Programmer's Manual, the description of the "brk"
> and "sbrk" calls note only that they change the system's notion of the
> lowest location not used by the program.  If the result of the call is to
> expand the address space of the process, there's no promise about the
> contents of the newly-available address space.

There is such a promise in the System V page for "brk"/"sbrk"; it promises
that the newly-available space will be zero-filled.

> Can system performance be improved by avoiding zero filling of the new
> memory?

Perhaps, although I suspect not by much.  The same could be said for the
zero-filling of newly-allocated blocks of files.  System *security* is
definitely improved by *not* avoiding this zero-filling; the data you get
from this may be somewhat random, but I wouldn't rely on that guaranteeing
that nobody can extract useful information from it.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)