[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mailutils (rf822 parser)
From: |
Alain Magloire |
Subject: |
Re: mailutils (rf822 parser) |
Date: |
Mon, 2 Apr 2001 00:31:36 -0400 (EDT) |
>
> I'm changing the return values, and checking all over the place
> for malloc failures. Turns out to be a major PITA. C sucks sometimes.
8-)
Indeed, it would be easier to throw and unwind the stack.
You can do it by cleverly using setjmp()/longjmp().
IIRC, this is how exceptions use to work in the old GCC releases.
You could unwind the stack by keeping the jump_buf and throw().
> And I'm not sure how to test it. Will electric fence detect unfreed
> memory on program exit?
No.
> Any other more portable suggestions? I
To check memory leaks?
There are different libraries, I sometime use dmalloc, it provides
post-fence checking, memory leaks checking etc ...
http://dmalloc.com/
http://sourceforge.net/projects/dmalloc/
The only thing annoying about dmalloc is that it does not give
a backtrace of where the memory leak occured. We have a usefull
little program inhouse that uses gcc __builtin_return_address() internall
functions to get a backtrace.
> think I can stub malloc by using GNU ld magic, might look into that.
>
What are you trying to accomplish?
parse822 leaks only when things failed 8-).
I can write a very dirty C implementation of try {} catch() throw();
If that can make things easier. If it is important to walk the stack
It is possible to make the throw() unwind.
It may seem a little heavy hand at first 8-) But can probably be
reuse in other parts.
> We've purify at work, it might do something useful.
>
It's a shame purify does not run on QNX/QRTP.
--
alain