How much should I cleanup?

How much should I cleanup?

[David Carlton]

When is it important to make sure that I have cleanups in place?  My
understanding is that it's important if I have control of a block of
memory that I want to xfree() after doing some work, but where that
xfree() might not be reached because of exceptional circumstances.

So, if that's correct: what are 'exceptional circumstances'?  I assume
error() and related functions count.  I don't know exactly what QUIT
does; do I have to be careful if there are QUIT's in between the
xmalloc() and the xfree()?  (Are those the only places where GDB pays
attention to ^C's?)  Any other situations?

Sigh.  C has its benefits, but ease of memory management isn't one of
them.  Every time I have to write a cleanup function, every time I
have to think about whether to alloca() memory for a string or to
xmalloc() it (and every time I can't alloca() it because I'm returning
the string in question), I get another grey hair.  (Though the grey
hair falls out soon thereafter, for better or for worse.)

David Carlton
carlton@math.stanford.edu

Re: How much should I cleanup?

[Andrew Cagney]

> When is it important to make sure that I have cleanups in place?  My
> understanding is that it's important if I have control of a block of
> memory that I want to xfree() after doing some work, but where that
> xfree() might not be reached because of exceptional circumstances.

Just assume the exception is the norm - you're going to need to do a 
clean-up.  The internals doco suggests several conventions.

> So, if that's correct: what are 'exceptional circumstances'?  I assume
> error() and related functions count.  I don't know exactly what QUIT
> does; do I have to be careful if there are QUIT's in between the
> xmalloc() and the xfree()?  (Are those the only places where GDB pays
> attention to ^C's?)  Any other situations?

Failed memory read, no frame.

> Sigh.  C has its benefits, but ease of memory management isn't one of
> them.  Every time I have to write a cleanup function, every time I
> have to think about whether to alloca() memory for a string or to
> xmalloc() it (and every time I can't alloca() it because I'm returning
> the string in question), I get another grey hair.  (Though the grey
> hair falls out soon thereafter, for better or for worse.)

Ah, yes.  C++ `is the answer' :-^

> David Carlton
> carlton@math.stanford.edu

Andrew

Re: How much should I cleanup?

[David Carlton]

On Sun, 16 Feb 2003 10:22:38 +0100, Andrew Cagney <ac131313@redhat.com> said:

>> So, if that's correct: what are 'exceptional circumstances'?  I assume
>> error() and related functions count.  I don't know exactly what QUIT
>> does; do I have to be careful if there are QUIT's in between the
>> xmalloc() and the xfree()?  (Are those the only places where GDB pays
>> attention to ^C's?)  Any other situations?

> Failed memory read, no frame.

Thanks.

>> Sigh.  C has its benefits, but ease of memory management isn't one
>> of them.  Every time I have to write a cleanup function, every time
>> I have to think about whether to alloca() memory for a string or to
>> xmalloc() it (and every time I can't alloca() it because I'm
>> returning the string in question), I get another grey hair.
>> (Though the grey hair falls out soon thereafter, for better or for
>> worse.)

> Ah, yes.  C++ `is the answer' :-^

Well, to handle this particular situation, a language with actual
garbage collection would be the most pleasant to program in.  (Let's
rewrite GDB in Scheme!)  But yes, C++'s improved support for
exceptions, memory management, and strings makes it much more pleasant
to program in compared to C when dealing with this sort of stuff.  (At
least once you have your old C pointer-usage habits drilled out of
you: writing exception-safe code in C++ isn't hard, it just doesn't
look quite like C code.)  Getting C++ to play well with GDB's existing
memory management/exception handling mechanisms would take a little
thought, though I don't see any reason why it couldn't be done.

David Carlton
carlton@math.stanford.edu