Re: Garbage collection

Douglas A. Gwyn wrote:
rbj@xxxxxxxxxxxxxx wrote:
This ... would clearly be a useful addition to the language,
reducing the burden on programmers to manage memory and increasing
security.

A proper economic analysis must include the negative consequences
as well. Some of them have been mentioned in other responses;
I'll add that encouraging programmers to lose track of when their
dynamic objects are valid does not "increase security".

Yes, it provokes less mistakes, by doing that automatically.
Since the programmer is no longer responsible for keeping accounting of
each memory piece, less mistakes are done in big software projects,
and the software is much more reliable.

There is
also insufficient generality, since there would be no destructors,
which are sometimes essential.

Destructors can be programmed as usual. Most garbage collectors also
allow you to force a free() if you *know* that an object is destroyed.

For instance:

void FreeData(DataStructure *p)
{
fclose(p->File);
destroyHandle(p->Handle);
// etc etc...
GC_free(p);
}

This destructor would be the same, but the call to
free() could be replaced with a call to GC_free,
or (much better) the call to free would be replaced
with
memset(p,0,sizeof(DataStructure));
to avoid using it after it is destroyed.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
.

Relevant Pages

  • Re: Forcing data into RAM memory only?
    ... Programmers often ask for help with a solution to a problem instead of ... security issue that will get a better answer in the security newsgroup. ... locking memory is a bad one, but I am not a security specialist. ... to disk unless the program wants to write it. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Lisp and low-level operating system development
    ... > more writing to memory that isn't allocated by accident. ... >> modern software design: that of security. ... By demanding that programmers should deal with _both_ ... It isn't an software virtual machine in the way you're envisioning. ...
    (comp.lang.lisp)
  • Re: Standards for developing secure software
    ... Many programmers see security as something extremly difficult. ... This is a job for the network and technet-guys to do. ... professional pride in the same way as saving memory and CPU power is. ...
    (SecProg)
  • RE: Standards for developing secure software
    ... I'm not an expert in security but I am a programmer and I do ... > I deal with leading programmers, and it seems to me that they are very ... > CPU ... I'm still more oriented towards CPU and memory, ...
    (SecProg)
  • Re: Determine calling function
    ... to encourage programmers to escape from following dogma mindlessly. ... ad absurdem of an insistence on checking malloc(), ... I don't know how much memory starting at ... Obviously a *hard* setrlimit() cannot be employed for throttling ...
    (comp.lang.c)