purge like utility in c

[Richard Heathfield]

jacob navia said:

Maybe. Better do not use [garbage collection].

Excellent advice.

Use malloc/free and do everything manually with all the associated bugs.

I'm happy to use malloc/free, but I see no need to include the bugs.

I was recommending the GC for other people that like caring about their
programs, their algorithms, their deadlines, instead of chasing
malloc/free bugs!!!

The claim "Jacob Navia can't use malloc/free without riddling his programs
with bugs" is a reasonable one, and if that's what you're claiming, I take
your word for it. But the claim "nobody else can either" is ridiculous.

 

[Richard Heathfield]

jacob navia said:

There is a whole INDUSTRY of software for chasing
malloc/free bugs. Huge software systems like valgrind,
purify, etc etc are built JUST TO CHASE THOSE BUGS.

Yeah. That's one reason they're so easy to find and fix. Duh.

 

[tedu]

Besides, all other languages do not provide with the efficiency
of C. Coupled with a good GC, the need for destructors, and
all the associated machinery disappears. You obtain a simpler,
easier to use language, without the problems of other "OO"
stuff.

does your garbage collection close files for me too?

 

[Keith Thompson]

You do:
#define malloc(a) GC_malloc(a)
#define free(a)

And that is it.

No, that is not it.

In addition to your two #defines, you need to tell the linker where to
find the GC_malloc() function. And if you don't add a #include for
whatever header contains the declaration of GC_malloc, you'll invoke
undefined behavior every time you call it, just like calling malloc()
without a "#include stdlib.h>". This will be a real problem on
systems with 32-bit int and 64 bit pointers, for example.

I wonder what else you've left out.

Most programs will work like this, unless (of course) they write
pointers to a file, or put their pointers in e-mail messages, or
whatever.

We have discussed this several times.

And every time it comes up, you advocate GC, but somebody else has to
mention the limitations. Garbage collection may be the greatest thing
since sliced bread, but nobody should try to use it without
understanding the caveats.

Garbage collection can work only if all pointer values in the program
are visible to the garbage collector at all times. That's probably
already the case for most programs, but ignoring the issue is
dangerous.

By the way, the limitations of valgrind are FAR more long. See my reply
to "Flash Gordon"...

I looked over it very briefly. It only works on a limited set of
platforms; that's ok if your code is portable and you have access to
such a system. (Yes, that's a real limitation that you should be
aware of.) Most of the other limitations seemed to apply only to code
that uses system-specific features. And all this was in response to a
brief *mention* of valgrind by Richard Heathfield. (I've never used
it myself, so I can't really comment further.)

 

[Ancient_Hacker]

Fellas! Come On!

Senator Ted Stevens has caught on! We're clogging up the Internet
pipes with all these long discussions!

I suggest we get the feds off our backs by coming up with a set of
well-known abbreviations, denoted by letters, thereby shortening these
interminable postings, something like:

A: I am wonderful, all-knowing, and generally infallible.
B: Use a garbage collector.
C: It's not C.
D: It's not K&R C.
E: you misdeclared main()
F: Use my wonderful C compiler, only slightly buggy.
G: Oh if only C had feature X of language Y!
H: Please fix my program below, it has an obscure problem.
I: Oh yes you can.
J: Oh no you can't.
K: I blow my nose in your general direction.

.... rest to be assigned as needed.

thereby all the stuff clogging the pipes can be reduced to a short
series of capital letters.
For even more brevity, we can just assume each posting ends with "K"
unless otherwise noted.

 

[gabs]

hi .. can we design a program in c which will point out the possible
memory leaks in any given c file and fix them.... i am trying to come
with something like this but do not know where to start...

any help on where to begin would be highly appriciated
kind regards
rahul

For each call to malloc you should have a call to free to let go of
that mem segment. A simplistic way of tracing any potential leaks is
discribed by Franek in his book: Memory as a Programming Concept in C
and C+, using the preprocessor:

#define malloc(size) debug_malloc(__FILE__,__LINE__,size)
#define free(ptr) debug_free(__FILE__,__LINE__,ptr)

protoypes:

void debug_malloc(const char *src,int line, size_t size)
void debug_free(const cahr *src,int line, void* ptr)

then simply link it to the definitions of these in your program and you
can have a handy reference of what was allocated and what was freed.
Good book and will help you think how you could fully implement your
question. I tried it out, but it can get a bit hairy as your code
becomes more complex...nice place to start though.

 

[Keith Thompson]

jacob navia said:

Maybe. Better do not use [garbage collection].

Excellent advice.

Use malloc/free and do everything manually with all the associated bugs.

I'm happy to use malloc/free, but I see no need to include the bugs.

I was recommending the GC for other people that like caring about their
programs, their algorithms, their deadlines, instead of chasing
malloc/free bugs!!!

The claim "Jacob Navia can't use malloc/free without riddling his programs
with bugs" is a reasonable one, and if that's what you're claiming, I take
your word for it. But the claim "nobody else can either" is ridiculous.

Garbage collection in C may or may not be a good solution for some
problems in some circumstances. The fact that its major advocate in
this newsgroup chooses to insult anyone who points out any potential
flaws shouldn't prevent anyone from looking into it. Ignoring jacob
navia needn't imply ignoring GC.

Of course, if you choose not to use GC, that's ok too; I make no
recommendation one way or the other.

 

[jmcgill]

hi .. can we design a program in c which will point out the possible
memory leaks in any given c file and fix them.

http://en.wikipedia.org/wiki/Memory_debugger

 

[jmcgill]

well, any use of malloc() without a later free() is going to leak....
But I think it's ttheoretically impossible to figure out what mallocs()
never do a free() without executing all possible paths thru the code
with all possible inputs.

Halting Problem, proven undecidable.

 

[Richard Tobin]

My understanding of valgrind is that you can use it without modifying your C
source code, so the program remains uncorrupted by the tool.

There are garbage collectors for C with that property. You just link
with a different version of malloc() and free(), where typically the
latter is a no-op.

And, having
used it to identify and remove any leaks from your program, the program
remains portable, and can still work independently of valgrind, so
portability is not affected.

Is a program that never calls free() portable? It just sees different
implementation limits from one which does.

will the program still work correctly without leaking memory even when that
program is moved to a platform where the garbage collector is unavailable?

A conforming C implementation is not required not to leak memory, is it?

Seriously, a conservative garbage collector is a reasonable approach
if your program fits certain common constraints and your portability
requirements match the collector in question. Much the same as deciding
to rely on a non-standard library, really.

-- Richard

 

[Richard Heathfield]

Keith Thompson said:

Garbage collection in C may or may not be a good solution for some
problems in some circumstances. The fact that its major advocate in
this newsgroup chooses to insult anyone who points out any potential
flaws shouldn't prevent anyone from looking into it.

Absolutely. Personally, I see no need for GC, but the world would be a
poorer place if we all did things the same way. It has been rightly said
that Lisp programmers think memory management is far too important to be
left to the programmer, whereas C programmers think memory management is
far too important to be left to the system.

Ignoring jacob navia needn't imply ignoring GC.

He makes a poor advertisement for it. If this is what garbage collection
leaves behind...

 

[Richard Heathfield]

Richard Tobin said:

There are garbage collectors for C with that property. You just link
with a different version of malloc() and free(), where typically the
latter is a no-op.

That's good to know. I would be happy to use such a garbage collector, at
least until I'd had a chance to look at the impact on performance. But it
wouldn't mean I'd stop doing my own memory management. It would, at best,
be a backup.

A conforming C implementation is not required not to leak memory, is it?

ROTFL - sorry, Richard, I obviously didn't phrase that very well.

Seriously, a conservative garbage collector is a reasonable approach
if your program fits certain common constraints and your portability
requirements match the collector in question. Much the same as deciding
to rely on a non-standard library, really.

Precisely so. And that's the problem with Jacob's continued advocacy of GC
here in third-party-library-blind comp.lang.c. It's no different to someone
constantly plugging GTK or ncurses. I have nothing against either of those
libraries, but if someone started telling me - here in comp.lang.c of all
places - that I was clearly a great fool for ignoring them in portable
code, I would use much the same arguments against them that I have used
against GC.

 

[jacob navia]

does your garbage collection close files for me too?

No, but it makes the coffee...

 

[jacob navia]

jacob navia said:

Maybe. Better do not use [garbage collection].

Excellent advice.

Use malloc/free and do everything manually with all the associated bugs.

I'm happy to use malloc/free, but I see no need to include the bugs.

I was recommending the GC for other people that like caring about their
programs, their algorithms, their deadlines, instead of chasing
malloc/free bugs!!!

The claim "Jacob Navia can't use malloc/free without riddling his programs
with bugs" is a reasonable one, and if that's what you're claiming, I take
your word for it. But the claim "nobody else can either" is ridiculous.

Garbage collection in C may or may not be a good solution for some
problems in some circumstances. The fact that its major advocate in
this newsgroup chooses to insult anyone who points out any potential
flaws shouldn't prevent anyone from looking into it. Ignoring jacob
navia needn't imply ignoring GC.

I did not insult anybody. You are lying.

I said (as you quote) that heathfield should not use the gc if he
can't get it to work.

For Mr Thomson this is an "insult". Be it.

 

[Richard Heathfield]

jacob navia said:

I did not insult anybody. You are lying.

I suggest you review your posting history more carefully.

I said (as you quote) that heathfield should not use the gc if he
can't get it to work.

That's like saying I shouldn't go in Canterbury Cathedral if I can't get the
door open. It's true that I can't get the door open, but the reason is not
that I'm no good at opening doors; it's that I'm not in Canterbury!

Similarly, the principal reason I can't get your suggested garbage collector
to work is that it is not installed on this system. It's that simple.

For Mr Thomson this is an "insult".

That's not what he said. Please learn to read. Thanks.

 

[Chris Dollin]

Besides, all other languages do not provide with the efficiency
of C.

C is good for micro-efficiency. It's not so good for the
kind of sweeping redesign that can get you macro-efficiency.

Coupled with a good GC, the need for destructors, and
all the associated machinery disappears.

In a GC language, the things that correspond to "destructors"
do other resourcy things, such a closing inaccessible file
objects: that's what Pop11's GC does, and what generalises to
its `destroy-action` property tables.

You obtain a simpler,
easier to use language, without the problems of other "OO"
stuff.

If I'm going to have the benefits of GC, I'd rather have a language
that knew how to exploit them.

Horses for courses: I have my choice between a racehorse, a carthorse,
a unicorn, or a pegasus, and don't see any compelling reason to
go all Dr Moreau on them.

 

[Keith Thompson]

Keith Thompson wrote: [...]

Garbage collection in C may or may not be a good solution for some
problems in some circumstances. The fact that its major advocate in
this newsgroup chooses to insult anyone who points out any potential
flaws shouldn't prevent anyone from looking into it. Ignoring jacob
navia needn't imply ignoring GC.

I did not insult anybody. You are lying.

Do not accuse me of lying unless you're very sure of your facts.

I said (as you quote) that heathfield should not use the gc if he
can't get it to work.

For Mr Thomson this is an "insult". Be it.

My name is Thompson, not Thomson. Copy-and-paste it if remembering it
is too much for you.

Here's what you actually wrote:

| Yes, do not use GC_malloc. You see?
| It doesn't work.
|
| Stay with "free" and "malloc" Heathfield. GC_malloc is too much for you.

Meanwhile, you've been telling the rest of us how easy GC is to use.
Of *course* it was an insult.

 

[Gordon Burditt]

If one is prepared to give up C standardness for garbage collection,

C was designed with a GC in mind.

You're a believer in "malevolent design", aren't you? C makes it
about as difficult as possible to implement garbage collection.
The impact is especially bad when the program has an open terabyte
file into which it *might* have stored pointers which will be read
back and used by the same instance of the running program, and
expect the pointed-at data to still be valid and not garbage-collected.

C already has a garbage collector. It just collects zero bytes all
the time.

I challenge any garbage collector that does not have knowledge of
the types of the data in malloc()ed memory (and therefore it doesn't
know what is and what isn't a pointer) to PROVE that it will always
free more than zero bytes even where there is leaked memory. Easier:
given an infinite loop that leaks memory on each iteration, prove
that the garbage collector will free any memory before memory allocation
fails (due to, say, running off a 32-bit pointer size limit).

 

[Richard Bos]

No, but it makes the coffee...

Well, of course it would... silly Froggie program, knows nothing about
beverages. Come back when it makes tea, as well. No, _real_ tea, not
that dishwater you serve in your country.

Richard

 

[Chris Dollin]

Well, of course it would... silly Froggie program, knows nothing about
beverages. Come back when it makes tea, as well. No, _real_ tea, not
that dishwater you serve in your country.

I don't think generic slurs like this should have a place in this
(or any other, really) newsgroup. (I'm not keen on the person-specific
slurs, either, actually.)