Garbage collection in C

[jacob navia]

Where did you get the idea that garbage collection was invented two
years ago by Lcc-win32? Garbage collection was invented many years
before Java, C# or Windows existed.

Please Al, try to be fair:

1) I always said that the GC is the work of Mr Boehm and not mine.
I just adapted his work to lcc-win32 two years ago.
2) I did not invent garbage collection. This is ridiculous. The first
garbage collector I wrote was a mark/sweep for a lisp interpreter
in 1987. And GC was already an old hat back then.

Why you need this polemic?

Got an argument?

Explain it.

jacob

 

[Alan Balmer]

Please do so.

You've convinced me. Bye.

 

[Stephen Howe]

#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.

I don't regard those arguments as valid arguments for GC. GC is one type of
resource management for memory. Since nothing else is offered, I assume that
you are proposing the same "incredible tedious accounting" for all _OTHER_
types of resource management, e.g. file handling.

There is a case for GC for some problems. This isn't it.

Stephen Howe

 

[jacob navia]

fail.

I don't regard those arguments as valid arguments for GC. GC is one type of
resource management for memory. Since nothing else is offered, I assume that
you are proposing the same "incredible tedious accounting" for all _OTHER_
types of resource management, e.g. file handling.

Yes, I am afraid you are right. Garbage collecting files should be done by the
operating system, I suppose, if at all.

As you can see from the discussion above, the mere fact of introducing the gc
makes for so many flame wars that any other innovation would be very difficult

There is a case for GC for some problems. This isn't it.

Can you explain?
I am curious.

jacob

 

[CBFalconer]

Where did you get the idea that garbage collection was invented
two years ago by Lcc-win32? Garbage collection was invented
many years before Java, C# or Windows existed.

Or C, or even Pascal. I think it originated with Lisp.

 

[Serve La]

I don't regard those arguments as valid arguments for GC. GC is one type of
resource management for memory. Since nothing else is offered, I assume that
you are proposing the same "incredible tedious accounting" for all _OTHER_
types of resource management, e.g. file handling.

It's almost (almost) getting funny, the resistance you people are showing
against GC. Files are used totally differently. I have never seen anybody
including myself chasing an "fclose" bug, or closing an invalid file
pointer.

 

[Ben Pfaff]

#define free(a) (a=NULL)

Bad idea. free()'s argument is not necessarily a modifiable
lvalue; e.g. free(malloc(1));

 

[Mark McIntyre]

As you can see from the discussion above, the mere fact of introducing the gc
makes for so many flame wars that any other innovation would be very difficult

You miss the point entirely, and I begin to think you're trolling.
Nobody is against GC, merely against your promotion of a specific
implementation of it.

Can you explain? I am curious.

As Dan Pop would say, "engage brain before posting"

 

[Richard Bos]

Please do so.

Your message is so constructive and full real arguments, that I think
it is better to ignore it.

comp.lang.c according to you,

I seriously considered using LCC as my C compiler for Windows. Yes,
seriously. But if this thread is a demonstration of its creator's love
for solid code, adherence to well-established good practice, and *sheer
bloody arrogance*, I'm now very seriously _re_-considering.

Congratulations. You just lost yourself a user. And a reader: *plonk*.

Richard

 

[Dave Vandervies]

It's almost (almost) getting funny, the resistance you people are showing
against GC. Files are used totally differently. I have never seen anybody
including myself chasing an "fclose" bug, or closing an invalid file
pointer.

I have.

And I'm not about to suggest that GC-style resource management would
have made the code work, or even made the bug less of a problem.
It definitely wouldn't've made it easier to find.

There are more things in heaven and earth,
Than are dreamt of in your philosophy.


dave
(For the curious: Another programmer's code was incorrectly using
freopen(...,stderr) instead of fopen(...). (And then closing the file.
On every call.) This invoked the "Just Happens To Work As Expected"
sort of undefined behavior until I tried to read from a file around
calls to this code, and (after two days) I realized that when my code
opened the file it got the FILE structure that stderr pointed at (which
had been closed, and was therefore available for re-use), and the call
into the buggy code clobbered my FILE.)

 

[Serve La]

I have.

And I'm not about to suggest that GC-style resource management would
have made the code work, or even made the bug less of a problem.
It definitely wouldn't've made it easier to find.

There are more things in heaven and earth,
Than are dreamt of in your philosophy.

Yes , I know that of course. But I was commenting on the fact that when
somebody proposes a useful feature and all answers he get are "but my files
are not cleaned up automatically" , "it can hide bugs in my algorithms" ,
"it does not work on platform xyz" , "now I can't do free(malloc(10));". Not
one positive answer. So the consensus among C people is that "GC is bad"?

 

[Serve La]

No.. *that* particular GC implementation is bad.. not GC itself.

The boehm collector? why?

 

[Andre]

No.. *that* particular GC implementation is bad.. not GC itself.

-Andre

 

[Arthur J. O'Dwyer]

The boehm collector? why?

Not Boehm. Jacob Navia's particular interface to Boehm. (Of course,
maybe Boehm's GC is bad too; I'm not a GC expert.)

I already said this in a personal email exchange with Jacob, but
here's what I find annoying/incorrect about his GC:

1) GC in general does not fit into the C language.

Because the C standard does not require GC, it is expected that a
C program will be able to run properly with or without GC. If it
doesn't clean up its own mallocs, then it's not properly-written
standard C. And if a program *does* run correctly without GC, why
on earth would you *add* GC to it? It's just library bloat at
that point.

2) This particular GC has a non-standard interface.

Jacob's first suggestion was to #define malloc GC_malloc. That
is AFAIK an invocation of undefined behavior, and isn't guaranteed
to work unless it is surrounded by

#ifdef __THIS_COMPILER_HAS_GC__

- except that of course the macro __THIS_COMPILER_HAS_GC__ does not
exist, so we're stuck with testing something defined by lcc-win32
(and, we hope, *only* by lcc-win32).

A much better interface would have been a #pragma directive; for
example,

#pragma LCCWIN32_GC

which requires much less thought by the programmer *and* has a better
chance IMHO of passing muster with the standards police.

3) The original proposal had a bug in it.

This is the #define free(a) (a=NULL) thing that several people pointed
out. Sure, it's trivial to fix, but the fact that it was included in
the proposal at all indicated that maybe Jacob hadn't put as much thought
into his design as he could have.

4) Real Programmers(tm) don't do garbage collection.

This one is a stereotype, of course, but you should realize that a lot
of the regulars in c.l.c are (or seem to be) Real Programmers(tm).
They program in C because they like the fine control, the clean
interface, and the raw power that the language provides. Garbage
collection is an attribute of higher-level Quiche Eater languages like
Lisp and Java, and you just shouldn't expect a ticker-tape parade from
the C programmers when you try to introduce it into C. It's the
psychology of the thing. C's been around for more than 20 years now
without GC; if you want GC that bad, use a language that has it built
in. That's how it is.


That pretty much sums up the points I've seen against this GC.

HTH,
-Arthur

 

[jacob navia]

Not Boehm. Jacob Navia's particular interface to Boehm. (Of course,
maybe Boehm's GC is bad too; I'm not a GC expert.)

I already said this in a personal email exchange with Jacob, but
here's what I find annoying/incorrect about his GC:

1) GC in general does not fit into the C language.

Because the C standard does not require GC, it is expected that a
C program will be able to run properly with or without GC. If it
doesn't clean up its own mallocs, then it's not properly-written
standard C. And if a program *does* run correctly without GC, why
on earth would you *add* GC to it? It's just library bloat at
that point.

With this logic you could say too:
1) library XYZ is not mentioned in the C standard
2) It is expected then, that any C program runs without the library XYZ
3) Therefore (!!!) library XYZ is BAD.

2) This particular GC has a non-standard interface.

Jacob's first suggestion was to #define malloc GC_malloc. That
is AFAIK an invocation of undefined behavior, and isn't guaranteed
to work unless it is surrounded by

#ifdef __THIS_COMPILER_HAS_GC__

- except that of course the macro __THIS_COMPILER_HAS_GC__ does not
exist, so we're stuck with testing something defined by lcc-win32
(and, we hope, *only* by lcc-win32).

The standard interface for the GC in lcc-win32 is:

#include <gc.h>

The ONLY thing to do then is:

#ifdef __LCC__

3) The original proposal had a bug in it.

This is the #define free(a) (a=NULL) thing that several people pointed
out. Sure, it's trivial to fix, but the fact that it was included in
the proposal at all indicated that maybe Jacob hadn't put as much thought
into his design as he could have.

As I told you the *standard* interface is to call GC_free(), i.e.
#define free GC_free

This is 100% compatible with the free() interface. BUT I think it is
better to use
#define free(a) (a=NULL)
since
1) This destroys the pointer to the freed memory
2) Doesn't call GC_free() eliminating any free() errors. Normally
you do not use free()

4) Real Programmers(tm) don't do garbage collection.

This one is a stereotype, of course, but you should realize that a lot
of the regulars in c.l.c are (or seem to be) Real Programmers(tm).

I see.

They program in C because they like the fine control, the clean
interface, and the raw power that the language provides. Garbage
collection is an attribute of higher-level Quiche Eater languages like
Lisp and Java, and you just shouldn't expect a ticker-tape parade from
the C programmers when you try to introduce it into C. It's the
psychology of the thing. C's been around for more than 20 years now
without GC; if you want GC that bad, use a language that has it built
in. That's how it is.

Look Arthur. As I told you I have an automatic drive. Many people are
real_drivers(tm)
and look at me with utmost comptent for saving me the effort of changing gears
several thousand times a day. I have seen with my own eyes a TAXI driver that
told me that.

"It doesn't hurt your hand at the end of the day?" I asked him.
Yes, he told me, but you know, this is driving, really, people that use
an automatic car are pimps.

I payed and left. The world is big and there must be people of all kinds
to fill it up.
Personally, I still use my automatic and if anybody calls me a pimp because
of that, I wouldn't care less.

Feel free to spend all that time debugging your manually done malloc/free
calls Arthur. It is your life, your programs.

But please do not try to forbid automatic garbage collection from the C language.
It is ridiculous, like if somebody would forbid automatic cars!!!

jacob

 

[Derk Gwen]

# one positive answer. So the consensus among C people is that "GC is bad"?

Never mistake the comp.lang.c clique for C people.

 

[Serve La]

# one positive answer. So the consensus among C people is that "GC is bad"?

Never mistake the comp.lang.c clique for C people.

Well, I'd say there are a lot of pretty good and experienced C programmers
in here.

 

[Larry Doolittle]

Because the C standard does not require GC, it is expected that a
C program will be able to run properly with or without GC. If it
doesn't clean up its own mallocs, then it's not properly-written
standard C.

There is a time and a place for C programs that clean up their
own mallocs. Long-running server processes, or user programs
that respond to an indefinitely long string of commands (text,
mouse-clicks, or brain waves, for all I care).

There is _also_ a time and a place for C programs that totally
ignore "memory leaks", and trust that the system will reclaim
any allocated memory when exit() is called. Obvious examples
are single-use programs on a "sufficiently large" machine,
or programs that do one thing and exit (e.g., *nix basename(1)).

Finally, many C programs are used in a context where any use
of malloc() itself is considered a bug, because there is no
guarantee of success, and success is mandatory. So of course
in this case there are no free()'s either.

Of course, none of this changes Arthur's conclusion, that
GC in C is a bad idea. People might be tempted to use it
in order to quickly (and without deep understanding) convert
programs conceived as "single-use on a sufficiently large
machine" into production code, but that is a horrible idea
for many more reasons than memory allocation. I'm all in
favor of quick prototyping, but the conversion from prototype
to production code is nothing to be taken lightly.

- Larry

 

[Derk Gwen]

# With this logic you could say too:
# 1) library XYZ is not mentioned in the C standard
# 2) It is expected then, that any C program runs without the library XYZ
# 3) Therefore (!!!) library XYZ is BAD.

The clique has in fact opined in the past that only legitimate functions are those
defined in the standard or defined in full. Reference to any other functions is deemed
off topic to reduce the cognitive load on the clique. The resulting flame wars do not
reduce the traffic, but rather increase it; topics that can be dealt with a simple
answer instead erupt into hundreds of posts over many weeks whining about off topicness.
(The clique is of course permitted to veer off topic.)

# > This is the #define free(a) (a=NULL) thing that several people pointed
# > out. Sure, it's trivial to fix, but the fact that it was included in
# > the proposal at all indicated that maybe Jacob hadn't put as much thought
# > into his design as he could have.
# >
#
# As I told you the *standard* interface is to call GC_free(), i.e.
# #define free GC_free

A typical clique response is to whine excessively about trivial issues. The idea being
to frustrate people outside the clique into silence.

 

[Jirka Klaue]

Derk Gwen wrote:
....

A typical clique response is to whine excessively about trivial issues. The idea being
to frustrate people outside the clique into silence.

I have the impression that momentary it is you, who is whining.

Jirka