Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!gatech!cuae2!ltuxa!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: net.unix-wizards
Subject: Re: brk's zero-fill behavior on VAXen
Message-ID: <1292@ttrdc.UUCP>
Date: Tue, 4-Nov-86 01:42:20 EST
Article-I.D.: ttrdc.1292
Posted: Tue Nov  4 01:42:20 1986
Date-Received: Wed, 5-Nov-86 21:09:20 EST
References: <7208@elsie.UUCP>
Organization: AT&T, Computer Systems Division, Skokie, IL
Lines: 22

In article <7208@elsie.UUCP>, ado@elsie.UUCP (Arthur David Olson) writes:
>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.  Yet on our VAX (and on yours, too, if you
>have one) the newly-available space is always zero filled.
>
>Can system performance be improved by avoiding zero filling of the new
>memory?

Possibly, but it would also create a security hole where one user could examine
random hunks of memory left behind by other users' processes.  Zeroing is the
quickest way to destroy this data.
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
	   go for it!  			allegra,ulysses,vax135}!ttrdc!levy