Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!swrinde!ucsd!rutgers!mcnc!rti!dg-rtp!dg-rtp.dg.com!goudreau
From: goudreau@dg-rtp.dg.com (Bob Goudreau)
Newsgroups: comp.lang.c
Subject: Re: Life after free?
Message-ID: <1990Oct5.230355.28113@dg-rtp.dg.com>
Date: 5 Oct 90 23:03:55 GMT
References: <26770@mimsy.umd.edu> <623@demott.COM> <5360:Oct421:09:4890@kramden.acf.nyu.edu>
Sender: usenet@dg-rtp.dg.com (Usenet Administration)
Reply-To: goudreau@dg-rtp.dg.com (Bob Goudreau)
Organization: Data General Corporation, Research Triangle Park, NC
Lines: 31

In article <5360:Oct421:09:4890@kramden.acf.nyu.edu>,
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) 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.
> 
> 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.

I think what he was thinking about was that on secure operating
systems, all memory that a process used should be wiped clean before
being made available to any other process.  This prevents the other
process from being able to accidentally see data it shouldn't.
There's no problem with the *original* process copying and storing
the data somewhere else; it's his data, after all.

But as you note, this is an OS issue, not a language issue; it must
be enforced at the system call layer.  On a UNIX system, this could
be accomplished by making the sbrk() call clear memory as it is
allocated.  The free() function, even if it actually calls sbrk()
to deallocate memory (it isn't required to), need not take any
memory-wiping action.

----------------------------------------------------------------------
Bob Goudreau				+1 919 248 6231
Data General Corporation
62 Alexander Drive			goudreau@dg-rtp.dg.com
Research Triangle Park, NC  27709	...!mcnc!rti!xyzzy!goudreau
USA