Re: [OB] Add cleanup, source.c

["Michael Snyder" <msnyder@sonic.net>]

> > >From gdbint.texinfo:
> >
> >    Your function should explicitly do or discard the cleanups it
> > creates.  Failing to do this leads to non-deterministic behavior since
> > the caller will arbitrarily do or discard your functions cleanups.
> > This need leads to two common cleanup styles.
>
> Humpf! I think I have contributed loads of patches that do not
> follow this advice. I'll be careful in the future, but sometimes
> it's not easy. For instance, when you have a function that has
> multiple possible exit points...

Yes, I don't feel right about this at all.  When was this paragraph
written?  It took me a long time to figure out how make_cleanup
worked, but it was also a long time ago, and I have been writing
cleanups without explicitly invoking do_cleanup for many many
years now.

This is how I understand the subsystem:

1) Every invocation of make_cleanup (or variants) throws a callback
onto a queue, that is guaranteed to be executed no later than the end
of the command loop cycle, whether due to error or normal return.

2) When you save an "old_cleanups" pointer, eg.
    struct cleanups *old_cleanups = make_cleanup (stuff);
it represents a watermark or bookmark in that queue.  Now there are
two things you can do with that watermark.

  a) discard_cleanups (old_cleanup) discards all the cleanups made
  AFTER that point (including "stuff").
  b) do_cleanups invokes all the cleanups made after that point.

3) But both of those actions have always been optional, and in my
understanding, only needed in special circumstances.  The normal
flow is to do nothing -- and the cleanups will be done by the
command loop, before the next command.

The whole purpose of this was to PREVENT having to look out
for multiple or abnormal exits from a function, so that you didn't
have to make sure you freed stuff before calling error or something.

Adding a requirement to explicitly call do_cleanups would go
against the original design purpose of the subsystem.