473,320 Members | 1,817 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Garbage collection in C

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


Nov 13 '05 #1
55 4058

"jacob navia" <ja*********@jacob.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.
Nov 13 '05 #2

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

"jacob navia" <ja*********@jacob.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.
Nov 13 '05 #3

"Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:jj*****************@newsread1.news.atl.earthl ink.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
Nov 13 '05 #4

"jacob navia" <ja*********@jacob.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.
Nov 13 '05 #5

"Serve La" <ik@hier.nl> 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.
Nov 13 '05 #6

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:bh**********@news8.svr.pol.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.
Nov 13 '05 #7

"Serve La" <ik@hier.nl> 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.
Nov 13 '05 #8

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message news:bh**********@news8.svr.pol.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.


Nov 13 '05 #9

"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:um********************************@4ax.com...
On Sun, 10 Aug 2003 10:34:43 +0200, in comp.lang.c , "jacob navia"
<ja*********@jacob.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
Nov 13 '05 #10
>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?


Does it correctly NOT free structures when pointers to them are
stored in a file, and later read back and used (during the same
execution of the program)? I believe this is allowed under ANSI C
and should not yield undefined behavior.

Gordon L. Burditt
Nov 13 '05 #11
jacob navia wrote:
.... snip ...
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.


You miss the point. The subject here is **portable** C
programming. Anything that is not portable to any compliant C90
or C99 (or even K&R) C compiler is OFF-TOPIC. Code written for
your extensions is highly non-portable, in fact it will not even
function on Windows with other compilers.

Now consider the following erroneous code, written assuming your
GC is in effect:

#define FREE(x) (x = NULL) /* your recommendation, I believe */

p = malloc(n * sizeof *p);
q = p;
/* use p and q */
FREE(p);
/* code using q */
FREE(q);

and failures in "code using q" are going to occur dependant on
when the GC system gets around to actually freeing p. With a
proper free of p ANY further use of q may trigger a run time error
on good quality systems - at any rate the action is probably
repeatable. A free of q should certainly trigger an error.

Now consider something like:

p = malloc(n * sizeof *p);
....
p++;
.... /* does the memory get destroyed in here? */
p--;
free(p);

which I believe to be completely valid C coding.

In addition your messages have excessive line length. No line
should exceed 80 characters, and 65 is much better.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 13 '05 #12
"jacob navia" <ja*********@jacob.remcomp.fr> wrote:
# 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:

As Boehm's code explains, it doesn't work on some programs (which disguise their
pointers).

--
Derk Gwen http://derkgwen.250free.com/html/index.html
The little stoner's got a point.
Nov 13 '05 #13

"Gordon Burditt" <go***********@sneaky.lerctr.org> wrote in message
news:bh********@library1.airnews.net...
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?


Does it correctly NOT free structures when pointers to them are
stored in a file, and later read back and used (during the same
execution of the program)? I believe this is allowed under ANSI C
and should not yield undefined behavior.

No.

If you have no pointers in RAM to an object it will be freed.

This is definitely NOT an application for a GC. The same if you
store pointers under the operating system control, like storing
pointers in the window extra bytes, under win32. Those objects
will not be visible to the GC and will be freed.
Nov 13 '05 #14

"CBFalconer" <cb********@yahoo.com> wrote in message news:3F***************@yahoo.com...
jacob navia wrote:
... snip ...

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.


You miss the point. The subject here is **portable** C
programming.


I repeat:
The work of Mr Boehm has been ported to windows, linux, and sun, among many others.
It is perfectly portable code in the greate majority of cases.
Anything that is not portable to any compliant C90
or C99 (or even K&R) C compiler is OFF-TOPIC.
Ok. We then go to the seventies. Ahhh what a big time then...
Code written for
your extensions is highly non-portable, in fact it will not even
function on Windows with other compilers.

Yes. No other C compiler under windows features a GC as standard environment.
But you can use the GC dll with code compiled by ANY windows compiler. Just
load the library (gc.dll) and you are done.
Now consider the following erroneous code, written assuming your
GC is in effect:

#define FREE(x) (x = NULL) /* your recommendation, I believe */

p = malloc(n * sizeof *p);
q = p;
/* use p and q */
FREE(p);
/* code using q */
FREE(q);

and failures in "code using q" are going to occur dependant on
when the GC system gets around to actually freeing p.
Yes. The same behavior as free().
With a
proper free of p ANY further use of q may trigger a run time error
on good quality systems - at any rate the action is probably
repeatable.
If free() destroys the data contained in the memory block, filling it
with data designed to provoke traps you MAY get an error if the
data contained pointers. Maybe you get bad results, that is all. The
same behavior as the gc.

A free of q should certainly trigger an error. On many systems freeing an object twice will provoke corruption of the
malloc system.
Now consider something like:

p = malloc(n * sizeof *p);
....
p++;
.... /* does the memory get destroyed in here? */
NO, since there is a pointer to the inner part of the object
p--;
free(p);

which I believe to be completely valid C coding.

It is
In addition your messages have excessive line length. No line
should exceed 80 characters, and 65 is much better.


Yes, I know. We are in the seventies and your terminal is an IBM3270.

Nov 13 '05 #15


Arthur J. O'Dwyer wrote:
and say, "Aha! Your problem must be with either 'mystruct' or
'mystruct->name'!" because the actual problem might be three
translation units away, in the line

pork = NULL;

and it simply happens that the GC has finally gotten around to
deleting 'pork', and has caused an error in the process (perhaps
the contents of '*pork' contain a pointer to 'mystruct', and
somewhere earlier the GC lost track of the reference count,
so that freeing 'pork' frees 'mystruct' unintentionally; maybe
something else happens).


In regard to this comment only, what you said cannot happen. If contents
of *pork contain a pointer to mystruct then the GC will not under any
circumstances decide to delete pork, at least not Bacon's Refernce
counting algorithm. Circular references are not a problem in many modern
ref-count GCs, namely Jikes RVM's JMTk (Jikes Memory management Toolkit).

-Andre

Nov 13 '05 #16
On Sun, 10 Aug 2003 10:34:43 +0200, "jacob navia"
<ja*********@jacob.remcomp.fr> wrote:
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.


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.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 13 '05 #17
On Mon, 11 Aug 2003 02:22:38 +0200, "jacob navia"
<ja*********@jacob.remcomp.fr> wrote:

and wrote, and wrote, and ...

I ignored the advertising the first time, but I am now very close to
filtering your messages as a continuing waste of my time and disk
space. I suggest you start your own newsgroup.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 13 '05 #18
In article <bh**********@news-reader4.wanadoo.fr>, jacob navia wrote:

Yes, I know. We are in the seventies and your terminal is an IBM3270.

I don't know about his terminal, but I read news in an 80x25 xterm. And
have many xterms on several virtual desktops. An I get really annoyed
when I have to resize one of the just to read news. I read your postings
(scrolling left and right) just because of your name. If somebody else
posted an article with too long lines, I'd just ignore his post. And
so would many other people.

Nov 13 '05 #19

"Alan Balmer" <al******@att.net> wrote in message news:jp********************************@4ax.com...
On Mon, 11 Aug 2003 02:22:38 +0200, "jacob navia"
<ja*********@jacob.remcomp.fr> wrote:

and wrote, and wrote, and ...

I ignored the advertising the first time, but I am now very close to
filtering your messages as a continuing waste of my time and disk
space.


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, is designed to answer questions like

HELP HELP!!!

I wrote
p[i++] = ++i;

and it doesn't work.

Serious discussions that go beyond the usual newbee questions should
go elsewhere. Obviously.

jacob

Nov 13 '05 #20

"Alan Balmer" <al******@att.net> wrote in message news:ve********************************@4ax.com...
On Sun, 10 Aug 2003 10:34:43 +0200, "jacob navia"
<ja*********@jacob.remcomp.fr> wrote:
Garbage collection is not restricted to Java or C#. Lcc-win32 introduced it more than 2 years ago inthe context of a Windows C implementation.


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

Nov 13 '05 #21
> #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
Nov 13 '05 #22
On Mon, 11 Aug 2003 18:30:56 +0200, "jacob navia"
<ja*********@jacob.remcomp.fr> wrote:
"Alan Balmer" <al******@att.net> wrote in message news:jp********************************@4ax.com...
On Mon, 11 Aug 2003 02:22:38 +0200, "jacob navia"
<ja*********@jacob.remcomp.fr> wrote:

and wrote, and wrote, and ...

I ignored the advertising the first time, but I am now very close to
filtering your messages as a continuing waste of my time and disk
space.


Please do so.


You've convinced me. Bye.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 13 '05 #23

"Stephen Howe" <SP*******************@tnsofres.com> wrote in message
news:3f***********************@reading.news.pipex. net...
#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.


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


Nov 13 '05 #24
Alan Balmer wrote:
<ja*********@jacob.remcomp.fr> wrote:
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.


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.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Nov 13 '05 #25

"Stephen Howe" <SP*******************@tnsofres.com> wrote in message
news:3f***********************@reading.news.pipex. net...
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.
Nov 13 '05 #26
"jacob navia" <ja*********@jacob.remcomp.fr> writes:
#define free(a) (a=NULL)


Bad idea. free()'s argument is not necessarily a modifiable
lvalue; e.g. free(malloc(1));
--
"I've been on the wagon now for more than a decade. Not a single goto
in all that time. I just don't need them any more. I don't even use
break or continue now, except on social occasions of course. And I
don't get carried away." --Richard Heathfield
Nov 13 '05 #27
On Mon, 11 Aug 2003 20:11:34 +0200, in comp.lang.c , "jacob navia"
<ja*********@jacob.remcomp.fr> wrote:
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.
There is a case for GC for some problems. This isn't it.


Can you explain? I am curious.


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

--
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 =---
Nov 13 '05 #28
"jacob navia" <ja*********@jacob.remcomp.fr> wrote:
"Alan Balmer" <al******@att.net> wrote in message news:jp********************************@4ax.com...
On Mon, 11 Aug 2003 02:22:38 +0200, "jacob navia"
<ja*********@jacob.remcomp.fr> wrote:

and wrote, and wrote, and ...

I ignored the advertising the first time, but I am now very close to
filtering your messages as a continuing waste of my time and disk
space.


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
Nov 13 '05 #29
In article <bh**********@news4.tilbu1.nb.home.nl>, Serve La <ik@hier.nl> wrote:
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.)

--
Dave Vandervies dj******@csclub.uwaterloo.ca
[A]s K&R didn't quite say: "We have tried to eliminate the brevity of the first
edition. Patterns are not a big idea, and they are not well-served by a small
book". --Richard Heathfield in comp.lang.c
Nov 13 '05 #30

"Dave Vandervies" <dj******@csclub.uwaterloo.ca> wrote in message
news:bh**********@tabloid.uwaterloo.ca...
In article <bh**********@news4.tilbu1.nb.home.nl>, Serve La <ik@hier.nl> wrote:
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.


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"?
Nov 13 '05 #31
No.. *that* particular GC implementation is bad.. not GC itself.

-Andre

Serve La wrote:
"Dave Vandervies" <dj******@csclub.uwaterloo.ca> wrote in message
news:bh**********@tabloid.uwaterloo.ca...
In article <bh**********@news4.tilbu1.nb.home.nl>, Serve La <ik@hier.nl>


wrote:
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.

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"?


Nov 13 '05 #32

"Andre" <fo********@hotmail.com> wrote in message
news:3f********@clarion.carno.net.au...
No.. *that* particular GC implementation is bad.. not GC itself.


The boehm collector? why?
Nov 13 '05 #33

On Wed, 13 Aug 2003, Serve La wrote:

"Andre" <fo********@hotmail.com> wrote in message
news:3f********@clarion.carno.net.au...
No.. *that* particular GC implementation is bad.. not GC itself.


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

Nov 13 '05 #34

"Arthur J. O'Dwyer" <aj*@andrew.cmu.edu> wrote in message
news:Pi************************************@unix47 .andrew.cmu.edu...

On Wed, 13 Aug 2003, Serve La wrote:

"Andre" <fo********@hotmail.com> wrote in message
news:3f********@clarion.carno.net.au...
No.. *that* particular GC implementation is bad.. not GC itself.
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.


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__
#include <gc.h>
#endif
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
Nov 13 '05 #35
# one positive answer. So the consensus among C people is that "GC is bad"?

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

--
Derk Gwen http://derkgwen.250free.com/html/index.html
I'm not even supposed to be here today.
Nov 13 '05 #36

"Derk Gwen" <de******@HotPOP.com> wrote in message
news:vj************@corp.supernews.com...
# 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.
Nov 13 '05 #37
Arthur J. O'Dwyer wrote:

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
Nov 13 '05 #38
# 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.

--
Derk Gwen http://derkgwen.250free.com/html/index.html
I have no respect for people with no shopping agenda.
Nov 13 '05 #39
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

Nov 13 '05 #40
>> 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"?

I claim that any real implementation of garbage collection for C
(the implementation NEED NOT be portable) has at least one of three
(fatal) problems:

(1) It never frees anything, in which case it can't be called garbage
collection.
(2) It frees stuff when it shouldn't. In particular, it doesn't
deal properly with pointers stored in files (and read back and used
later by the same invocation of the program) or encrypted pointers
stored in files, or encrypted pointers stored in memory.
(3) It uses excessive resources during garbage collection.
(Yes, this is subjective, but I classify reading whole hundred-terabyte
files looking for pointers that aren't there as excessive.)

C already has (1).

(2) is not an issue for at least 99.99% of real programs, but it
does introduce problems doing something that ANSI C says is acceptable.

(3) is likely caused by trying to fix (2).

Why do you insist on being obtuse? Use of GC in a portable C
program is bad, unless the complete GC system is written in
portable C and published as part of that program. Otherwise the
program becomes non-portable.
This is true if a number of things available from third-party
libraries are substituted for GC: say, networking, graphics, database
access, etc.
However, I have grave doubts that it is possible to write a
completely portable GC system.
I have grave doubts that it is possible to write a practical GC
system for C that doesn't have at least one of the problems listed
above. That business about allowing pointers in files makes it
really hard.

My standard for C + GC: take the ANSI C standard, and add a statement
that a program may malloc() memory without freeing it, memory that
no longer has any reference to it anywhere is freed automatically
(eventually), putting off running out of resources. Anything that
doesn't cause Undefined Behavior in plain ANSI C shouldn't cause
it in C + GC.

Perhaps it could require that the program:

#include <stdlib.h>

int main(void) {
char *p;

while (1) {
p = malloc(1);
}
}

shouldn't ever run out of memory.
Remember, this implies making no
assumptions other than those stated in the C standard. For
example, there is no way of scanning all memory in use for any
particular value.


I'm not going to require that the IMPLEMENTATION of GC be written
in portable C (the implementation of fopen() needn't be portable
either). It won't help.

Gordon L. Burditt
Nov 13 '05 #41
"Serve La" <ik@hier.nl> wrote in message
news:bh*********@news2.tilbu1.nb.home.nl...

"Dave Vandervies" <dj******@csclub.uwaterloo.ca> wrote in message
news:bh**********@tabloid.uwaterloo.ca...
In article <bh**********@news4.tilbu1.nb.home.nl>, Serve La <ik@hier.nl> wrote:
It's almost (almost) getting funny, the resistance you people are showingagainst GC. Files are used totally differently. I have never seen anybodyincluding myself chasing an "fclose" bug, or closing an invalid file
pointer.

.... 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"?

Ok, I'll say it; Garbage Collections is Evil!

The C motto is / was / will always be "Trust the programmer". No safety
nets. No namby-pamby helpful error messages. If you don't know what's wrong
then go back to writing BASIC, you simp!

"Oh, Gosh, I have a memory leak..." NO, you have a bad design! Learn to
program, you idiot!

If you can't clean up your own messes, you are not only not a programmer,
but also not fully human.

Ar*****@sbcglobal.net
Nov 13 '05 #42
Serve La wrote:
So the consensus among C people is that "GC is bad"?


No. I think GC is *wonderful*; I've been programming in GCy languages
for (pause) more than 30 years.

But GC doesn't fit naturally *into C* [despite Hans's fine work], and
doesn't fit into many of the contexts in which C is used, and *is not
portable* in the CLC sense - you can't assume that your target platform
will have it. If you're willing to accept the implementation constraints
it implies, then fine, but it's not CLC-topical.

If you really want to use GC in your application or design, you might
want to consider whether you want to use C at all; GC enables a whole
bunch of idioms that C just does not support, higher-order functions
to name the most obvious. There's Smalltalk and Lisp and Pop11 and
Prolog and drat-begins-with-E-telecoms-associated, for example, or if
you're desparate, you can use Java.

--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgrou...mp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambl...me_to_clc.html
Nov 13 '05 #43

On Thu, 14 Aug 2003, Shill wrote:
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.


C is over 30 years old. Are you saying that it was given a garbage
collector in the 80s? Are you talking about C++?


Of course not! and Of course not! respectively.

BTW, K&R1 was published in 1978 according to my sources, and
modern C was not standardized until 1989. The current year is 2003.

-Arthur

Nov 13 '05 #44
> BTW, K&R1 was published in 1978 according to my sources, and
modern C was not standardized until 1989. The current year is 2003.


C was designed in the early 1970s. The current year is 2003 :)

Nov 13 '05 #45
Standard C allows pointer values to be hidden away anywhere the
programmer likes, erased from memory, and then read back in; as long
as all the bits are retrieved consistently, the pointer is still
valid. A GC subsystem that assumes that only pointers stored in
memory (or registers) are valid, and that anything not pointed to by a
valid pointer may be safely deallocated, will break some valid C
programs. (A GC subsystem that doesn't make such an assumption
probably won't collect much garbage.)

An implementation that implements a language that's ISO C, minus the
guarantee that pointers remain valid when they're not in memory, plus
GC, implements a language that isn't really C. It may be a very
interesting and useful language. It may even look a lot like C200X.
And it will probably support almost all existing valid C code. (Do
you know of any real world programs that erase pointer values from
memory, then later retrieve them and expect them to be valid? I
don't.) But it isn't really C.

Whether such a not-quite-C language is topical for this newsgroup is
left as an exercise for the ongoing flamewar. On the other hand,
discussion of whether it's topical (i.e., of whether a conforming C
implementation may legally provide GC) seems quite topical, even if
the answer happens to be no.

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 13 '05 #46
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?

--
Jussi Ekholm <je*****@luukku.com> | ekh on IRCNet (#bbs.fi, #irssi)
http://erppimaa.no-ip.org:8080/ | and Freenode (#irssi, #mutt)
Nov 13 '05 #47
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".

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

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #48
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()?

I know this problem can be circumvented by putting parantheses around
'free', but errors made by omitting this can be very difficult to see.

I would be more inclined to use GC_malloc/GC_free throughout the
program, and redefine these if no GC is available.
Nov 13 '05 #49

"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!

Nov 13 '05 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Bob | last post by:
Are there any known applications out there used to test the performance of the .NET garbage collector over a long period of time? Basically I need an application that creates objects, uses them, and...
6
by: Ganesh | last post by:
Is there a utility by microsoft (or anyone) to force garbage collection in a process without have access to the process code. regards Ganesh
11
by: Rick | last post by:
Hi, My question is.. if Lisp, a 40 year old language supports garbage collection, why didn't the authors of C++ choose garbage collection for this language? Are there fundamental reasons behind...
34
by: Ville Voipio | last post by:
I would need to make some high-reliability software running on Linux in an embedded system. Performance (or lack of it) is not an issue, reliability is. The piece of software is rather simple,...
5
by: Bob lazarchik | last post by:
Hello: We are considering developing a time critical system in C#. Our tool used in Semiconductor production and we need to be able to take meaurements at precise 10.0 ms intervals( 1000...
8
by: mike2036 | last post by:
For some reason it appears that garbage collection is releasing an object that I'm still using. The object is declared in a module and instantiated within a class that is in turn instantiated by...
28
by: Goalie_Ca | last post by:
I have been reading (or at least googling) about the potential addition of optional garbage collection to C++0x. There are numerous myths and whatnot with very little detailed information. Will...
56
by: Johnny E. Jensen | last post by:
Hellow I'am not sure what to think about the Garbage Collector. I have a Class OutlookObject, It have two private variables. Private Microsoft.Office.Interop.Outlook.Application _Application =...
350
by: Lloyd Bonafide | last post by:
I followed a link to James Kanze's web site in another thread and was surprised to read this comment by a link to a GC: "I can't imagine writing C++ without it" How many of you c.l.c++'ers use...
158
by: pushpakulkar | last post by:
Hi all, Is garbage collection possible in C++. It doesn't come as part of language support. Is there any specific reason for the same due to the way the language is designed. Or it is...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.