Garbage collection in C

[jacob navia]

Tired of chasing free(tm) bugs?

Get serious about C and use lcc-win32. The garbage collector designed by Boehm is the best of its
class. Very simple:

#define malloc GC_malloc
#define free(a) (a=NULL)

NICE isn't it?

No more chasing free() bugs, no more this incredible tedious accounting where it is SO easy to miss
some pointer. Leave to the machine what the machine does best: the boring accounting work and
concentrate in your algorithm, the thing humans do best and where machines fail.

Garbage collection is not restricted to Java or C#. Lcc-win32 introduced it more than 2 years ago in
the context of a Windows C implementation. A DLL you link with your program, a header file more, and
MANY hours of debugging less.

And this code is portable, since Boehm's work runs in many Unices, workstations and many types of
machines.

Garbage collection means less headaches for you, and simpler programs to maintain and debug. The
amount of buggy code that is dedicated to manage the allocation system can be significant and it is
by experience one of the most difficults part to debug.

Scrap it!

http://www.cs.virginia.edu/~lcc-win32

jacob

[Malcolm]

"jacob navia" <ja*********@ja cob.remcomp.fr> wrote in message

Tired of chasing free(tm) bugs?

Get serious about C and use lcc-win32. The garbage collector
designed by Boehm is the best of its class.

There's something to be said for garbage collection.

One problem is that failure to free() a pointer often doesn't just indicate
that the programmer forgot to make the call, but that there is something
else wrong with the algorithm. masking this might make such bugs harder to
find.

[Serve La]

"Malcolm" <ma*****@55bank .freeserve.co.u k> wrote in message
news:bh******** **@news8.svr.po l.co.uk...

"jacob navia" <ja*********@ja cob.remcomp.fr> wrote in message

Tired of chasing free(tm) bugs?

Get serious about C and use lcc-win32. The garbage collector
designed by Boehm is the best of its class.
There's something to be said for garbage collection.

One problem is that failure to free() a pointer often doesn't just

indicate that the programmer forgot to make the call, but that there is something
else wrong with the algorithm. masking this might make such bugs harder to
find.

I really don't understand what you mean here. Please give an example of a
wrong algorithm where memory isn't freed.

If you mean that the algorithm is wrong in the sense that some code paths
don't come across the free's, that's exactly what you win with GC.

[jacob navia]

"Martin Ambuhl" <ma*****@earthl ink.net> wrote in message
news:jj******** *********@newsr ead1.news.atl.e arthlink.net...

jacob navia wrote:

Tired of chasing free(tm) bugs?

Get serious about C and use lcc-win32.

I admit that I like lcc, even in its win32 incarnation. However, this is
the second thread in the last few days in which you have been pushing this
product. Since it is available free, calling what you are doing spamming
is not accurate. But it is certainly redolent of spam.

Hi Martin
Yes, it is promoting lcc-win32. I have been working the last 8 years into making it a nice compiler,
and I would like that people know about it, and all the features I have been adding to it.

As far as I know, it is the only C compiler where there isn't a C/C++ tag on it. It is a C compiler,
albeit a modern one. I believe in this language because of its simplicity and power of expression. I
wanted to stress that GC is available in C, not only in JAVA (tm) or C# (tm). By the way, when we
speak here about trade-mark products like JAVA or C# isn't it that "pushing" a product?

I have no publicity budget so I have to promote lcc-win32 the old way: by just saying it so.

Sorry if I disturbed you

jacob

[Serve La]

"jacob navia" <ja*********@ja cob.remcomp.fr> wrote in message
news:bh******** **@news-reader3.wanadoo .fr...

As far as I know, it is the only C compiler where there isn't a C/C++ tag on it.

Uhoh, now you'll get a list of "pure" C compilers
It is a C compiler,
albeit a modern one. I believe in this language because of its simplicity

and power of expression.

This is what most people say about C and I agree.

No specialized template arguments with default value, generating source for
a member function template policy class that's using a protected friend
which it also inherits from but without a virtual destructor :-)
It's way out of control with these C++'ers.

[Malcolm]

"Serve La" <[e-mail]> wrote in message

I really don't understand what you mean here. Please give an example > of a wrong algorithm where memory isn't freed.

You've got a linked list. You insert and delete sub-lists in amny places in
your code.
In one place, you make a mistake, so that a section of nodes is orphaned.
Really they were meant to be appended to the tail of the list but omitted
the line
last->next = sublist;

Now if you don't have garbage collection, on freeing the list the orphan
nodes won't be freed. Using a leak detector, you will see "memory leak" and
"oh no, something is wrong here. Eventually you will come to your error.
The real problem is not that you are wasting a few bytes of memory on the
orphan nodes, but that they should be appended to the main list. They might
be objects for collision detection, for instance, and it might not be
immediately obvious that some items are missing.

[Serve La]

"Malcolm" <ma*****@55bank .freeserve.co.u k> wrote in message
news:bh******** **@news8.svr.po l.co.uk...

You've got a linked list. You insert and delete sub-lists in amny places in your code.
In one place, you make a mistake, so that a section of nodes is orphaned.
Really they were meant to be appended to the tail of the list but omitted
the line
last->next = sublist;

Now if you don't have garbage collection, on freeing the list the orphan
nodes won't be freed. Using a leak detector, you will see "memory leak" and "oh no, something is wrong here.

two things:
1. you don't need a memory leak detector for errors like that. A test case
and a test run would show you that the data isn't added properly.
2. if you clutter your code with linked list logic all over the place, you
don't need a memory leak detector to tell you you have a problem.

[Malcolm]

"Serve La" <[e-mail]> wrote in message

two things:
1. you don't need a memory leak detector for errors like that. A test
case and a test run would show you that the data isn't added properly.
No, but you will find the bug quicker with the leak detection.
2. if you clutter your code with linked list logic all over the place, you
don't need a memory leak detector to tell you you have a problem.

Sometimes it isn't easy to write neat programs. Maybe the fact that we have
such a bug tells us that the time has come to do some surgery on the code.

Checking that free() is invoked correctly shouldn't be your only or even
your major bug-detecting strategy. However forcing programmers to explicitly
free() all memory they allocate is often useful in showing up design flaws.

[jacob navia]

"Malcolm" <ma*****@55bank .freeserve.co.u k> wrote in message news:bh******** **@news8.svr.po l.co.uk...

[snip] Checking that free() is invoked correctly shouldn't be your only or even
your major bug-detecting strategy. However forcing programmers to explicitly
free() all memory they allocate is often useful in showing up design flaws.

It *could* be. But garbage collection is a great tool when you want to avoid nasty freeing bugs like
making sure all aliases to the object you are going to free are dead and they will never be used
again.

There is "magic bullet" of course, I am not trying to sell you something since my compiler system is
free. It is a great tool for PC applications, where there are no real time and memory constraints.

[jacob navia]

"Mark McIntyre" <ma**********@s pamcop.net> wrote in message
news:um******** *************** *********@4ax.c om...

On Sun, 10 Aug 2003 10:34:43 +0200, in comp.lang.c , "jacob navia"
<ja*********@ja cob.remcomp.fr> wrote:

(advertising)

I seem to recall that advertising, even for nominally free products,
is frowned upon in CLC, even possibly against the posting rules.
Garbage collection is not something that can be done only in JAVA or C#. There was a thread that
discussed those messages, a few posts ago. I think it is important to underline that garbage
collection was done in C well before those languages even existed.
Doesn't bother me, although it increases the likelihood of me never
using the product,
Yes, it is a good attitude. Do not use it if you like. this is a forum, and everyone is entitled to
their opinions.
but your post is additionally offtopic as far as I
can see,
Garbage collection is a necessary thing that has been always frowned upon in forums, by people that
seem to like those horrible sessions of malloc/free debugging.

One of the main advantages I always hear of "Java over C" or "C# over C" is the

"We have garbage collection guys. You don't".

It is simply not true. I think advertising what Mr Boehm has done, and I suppose you do not doubt
the quality of his work, is on topic here. This modifies a lot the language itself.

For instance, we always hear about the destructors in other languages that automatically reclaim
memory. Well, with a GC you do not need that you see?

There is no need either to use complicated setjmp/longjmps to "cleanup" when you do a longjump
somewhere else, freeing all those blocks of memory. They will be freed automatically.

And, above all, there is no longer that incredibly tedious accounting chores!

The simplification in programming is staggering. How much time we have lost tracking those memory
allocation bugs?

has a misleading Subject line,
No. The subject line is crystal clear: "Garbage collection in C". Isn't that very clear to you?
and is hyperbolic to boot.
Nothing "hyperbolic there" but just the facts. The facts that are always frowned upon in this forums
by a kind of "conservativism " where we put the C language as a frozen block of specs that we can
never improve.

Garbage collection improves the programming in C, and simplifies system construction. No longer is
it necessary to keep an error-prone accounting of each memory block you see?

This sounds like an hyperbole because it sounds immedately so good that it looks exaggerated. But it
is not. It is really better.

That I don't like.

Like, dislike.

Let's discuss the issues Mark. The issues here are clear.

What is your opinion?

You didn't tell us at the end.

jacob