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

[jacob navia]

"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bh**********@sparta.btinternet.com...

Jussi Ekholm wrote:

jacob navia <ja*********@jacob.remcomp.fr> wrote:

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.
I apologize if this is a stupid question (although, I recall someone
saying "there is no stupid questions, only stupid people...), but what
is this "magic bullet" you're talking about?

Jacob, I'm sure, meant to write "there is no silver bullet".

Exactly. Thanks for the correction :-)
In "The Mythical Man-Month" by Fred Brooks, there is a chapter entitled "No
Silver Bullet - Essence and Accident in Software Engineering". The chapter
is subtitled: "There is no single development, in either technology or
management technique, which by itself promises even one order-of-magnitude
improvement within a decade in productivity, in reliability, in
simplicity".

[Mark Gordon]

On Sat, 16 Aug 2003 19:39:36 +0200
"jacob navia" <ja*********@jacob.remcomp.fr> wrote:

"Bjorn Reese" <br****@mail1.stofanet.dk> wrote in message
news:3F***************@mail1.stofanet.dk...

jacob navia wrote:

#define free GC_free

[...]

#define free(a) (a=NULL)

What about memory allocated by third-party libraries, which was not
allocated using GC_malloc() and thus must be freed with free()?

Memory not allocated by the collector will not be touched of course.
External libraries work without any problems!

The point was that if the external library passes you a pointer that you
are expected to free, then after your redefinition of free the following
code fragment gives a memory leak

{
char *derf;
derf = foo(); /* foo is in library and returns pointer from malloc */
/* do some stuff */
free(derf);
}

I would also point out that if you don't have to free some dynamically
allocated memory but other pieces of dynamically allocated memory do
need freeing you (or at least I) am more likely to make a mistake and
either use the standard free on a pointer that should be left for the GC
or not call it on a pointer to memory provided (though a library) by
malloc.
--
Mark Gordon

[jacob navia]

"Mark Gordon" <sp******@flash-gordon.me.uk> wrote in message
news:20030816213841.42106cd1.sp******@flash-gordon.me.uk...

The point was that if the external library passes you a pointer that you
are expected to free, then after your redefinition of free the following
code fragment gives a memory leak

{
char *derf;
derf = foo(); /* foo is in library and returns pointer from malloc */
/* do some stuff */
free(derf);
}

I would also point out that if you don't have to free some dynamically
allocated memory but other pieces of dynamically allocated memory do
need freeing you (or at least I) am more likely to make a mistake and
either use the standard free on a pointer that should be left for the GC
or not call it on a pointer to memory provided (though a library) by
malloc.

Yes, this could be a problem. Fortunately libraries that pass allocated
memory expecting you to free it are very rare. This is because they can
only work with one compiler system. The "malloc" implementations are
not compatible: you can't free with gcc's free() a piece of memory allocated
with MSVC, for instance.

That's why this example is not very real. Most libraries are designed to
work with many compiler systems and do not rely on the user freeing memory.
Usually they give an interface where you call some API to free the
allocated memory.

jacob

[Mark McIntyre]

On Sat, 16 Aug 2003 10:57:25 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:

In "The Mythical Man-Month" by Fred Brooks, there is a chapter entitled "No
Silver Bullet - Essence and Accident in Software Engineering". The chapter
is subtitled: "There is no single development, in either technology or
management technique, which by itself promises even one order-of-magnitude
improvement within a decade in productivity, in reliability, in
simplicity".

Like all generalisations, this one is wrong. Counterexamples:

Clean water in london wiped out cholera inside a few year
pennicilin stopped a wide range of deaths
consumer GPS in the 1990s reliably position you to within feet
and what about HTTP?

I guess you could argue that none of these is a "single development".
Hmm, in that case, nothing ever is.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Arthur J. O'Dwyer]

On Sat, 16 Aug 2003, jacob navia wrote:

"Mark Gordon" <sp******@flash-gordon.me.uk> wrote ...

The point was that if the external library passes you a pointer that you
are expected to free, then after your redefinition of free the following
code fragment gives a memory leak

{
char *derf;
derf = foo(); /* foo is in library and returns pointer from malloc */
/* do some stuff */
free(derf);
}
Simple answer: GC_free(x) can look to see if it allocated x. If it
did, it marks it for cleanup. If it didn't, it can pass x on to the
implementation's 'free' function (and kind of assume the user must
know what he's doing). Not a silver bullet, but avoids memory leaks.
I would also point out that if you don't have to free some dynamically
allocated memory but other pieces of dynamically allocated memory do
need freeing you (or at least I) am more likely to make a mistake and
either use the standard free on a pointer that should be left for the GC
or not call it on a pointer to memory provided (though a library) by
malloc.
Yes, this could be a problem. Fortunately libraries that pass allocated
memory expecting you to free it are very rare. This is because they can
only work with one compiler system. The "malloc" implementations are
not compatible: you can't free with gcc's free() a piece of memory allocated
with MSVC, for instance.

Well, *if* the library is compiled with the same object file format as
the compiler's generated code, then the library function (say Strdup())
doesn't actually contain any memory management code. It just contains
a call to '_malloc' or '@_MALLOC' or whatever, and when the linker
does its magic, the '_malloc' in the library code and the '_free' in
the user code match up and everyone's happy.

Of course, last I checked you couldn't use MSVC library files with GCC
object files, so all bets are off. But it's a file format problem,
not a library problem.
That's why this example is not very real. Most libraries are designed to
work with many compiler systems and do not rely on the user freeing memory.
Usually they give an interface where you call some API to free the
allocated memory.

Strdup.

Also, I'm in the middle [or end, depending on motivation] of writing
an image-format library that has lots of functions like

int ReadPPM(const char *fname, unsigned char *(*data)[3], int *w, int *h);

for which the user is expected to call 'free' on the data pointer
when necessary:

unsigned char (*data)[3];
int w, h;
int rc = ReadPPM("input.ppm", &data, &w, &h);
if (rc < 0)
return EXIT_FAILURE;
else {
process(data, w, h);
free(data);
return 0;
}

Obviously the answer to this particular case is, "Don't use GC for
your image-format library's applications," and that's perfectly
reasonable. Just pointing out that there probably are a lot of
libraries in C for which GC would eventually be a problem.

-Arthur

[Zeljko Vrba]

In article <bh**********@news-reader5.wanadoo.fr>, jacob navia wrote:

Yes, this could be a problem. Fortunately libraries that pass allocated
memory expecting you to free it are very rare. This is because they can
only work with one compiler system. The "malloc" implementations are
not compatible: you can't free with gcc's free() a piece of memory allocated
with MSVC, for instance.

Wrong. Shared and static libraries will contain only reference to malloc
and free calls. They will be resolved only when the final program is
linked (or, in case of dynamic linking, when it is run). At that point
a single implementation of malloc will be used an all is well. As long as
MS linker can read gcc's object files (and vice-versa), there is no problem in
mixing different compilers at all.