Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!elroy.jpl.nasa.gov!thyme!kaleb
From: kaleb@thyme.jpl.nasa.gov (Kaleb Keithley	)
Newsgroups: comp.lang.c
Subject: Re: Life after free?
Message-ID: <1990Oct5.011711.2381@thyme.jpl.nasa.gov>
Date: 5 Oct 90 01:17:11 GMT
References: <623@demott.COM> <5360:Oct421:09:4890@kramden.acf.nyu.edu> <1990Oct5.002416.3196@nntp-server.caltech.edu>
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 28

In article <1990Oct5.002416.3196@nntp-server.caltech.edu> manning@nntp-server.caltech.edu (Evan Marshall Manning) writes:
>In article <623@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes:
>>     It should be noted that in secure systems, free() will clear the memory.
>
>brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>
>>That would be quite amusing, since there's absolutely no concept of
>>security within C. If you can free it, you can copy it out and save it
>>first.
>
>You're missing the point.  Of course you can do what you like with your
>data.  But when you free() it you return it to the OS.  And anybody else
>can end up with your data when they next malloc().

Which OS is that on?  At the risk of exhibiting "small world" syndrome,
in UNIX, malloc and free work within the confines of the heap, which
is given to the process through the sbrk system call.  No other process
can *normally* gain access to a process' heap space without generating 
a memory exception of some kind and dumping core.  Memory given to a process
through sbrk is returned to the system memory pool only when the program
terminates.  I'd hazard that other multi-tasking OS's like VMS behave
similarly.

-- 
Kaleb Keithley                      Jet Propulsion Labs
kaleb@thyme.jpl.nasa.gov

Stirring up trouble again.