Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!umich!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.c
Subject: Re: Life after free?
Message-ID: <9269:Oct502:58:0490@kramden.acf.nyu.edu>
Date: 5 Oct 90 02:58:04 GMT
References: <623@demott.COM> <5360:Oct421:09:4890@kramden.acf.nyu.edu> <1990Oct5.002416.3196@nntp-server.caltech.edu>
Organization: IR
Lines: 19

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().

And any sane operating system will zero-fill pages that it gives to a
process, rather than adding slow code to free(). And no UNIX malloc()
I've seen even tries to return memory to the system---it'll probably
just have to allocate it again. And this is comp.lang.c, where the word
``security'' means something like ``modularity'' or what might now be
called ``data hiding'' or ``object-oriented programming''.

---Dan