Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Michael Snyder" <msnyder@sonic.net>
To: "Eli Zaretskii" <eliz@gnu.org>
Cc: <drow@false.org>, <Michael.Snyder@access-company.com>,
	        <gdb-patches@sourceware.org>
Subject: Re: [OB] Add cleanup, source.c
Date: Sat, 30 Jun 2007 16:39:00 -0000	[thread overview]
Message-ID: <000b01c7bb2f$d88684e0$677ba8c0@sonic.net> (raw)
In-Reply-To: <uejjtmz8z.fsf@gnu.org>


> > > 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.
> >
> > Yeah, that text was written by Andrew in 2003.  Before that we
> > had some text written by Eli in about 2001, also saying that you
> > should call do_cleanups.
> >
> > <ahem>
> > Don't mean to be a curmudgeon, but I go back way before that.  ;-)
> >
> > Here's how version 1.1 of the document read:
>
> Sorry, I'm confused: where exactly is the current gdbint.texinfo text
> wrong?
>
> Are you saying that the non-deterministic behavior mentioned in the
> manual is a red herring?  But the explanation it provides (the fact
> that some other function further on could discard_cleanups) seems to
> provide valid basis for that, doesn't it?

Depends on what the "cleanups" are, I suppose.  Those I'm familiar
with are mostly xfrees, fcloses, etc.  Doesn't really matter what
order they are performed in, so long as they get done before the
next command loop cycle.

Can you give me an example of such non-deterministic behavior?




  reply	other threads:[~2007-06-30 16:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-28 22:35 msnyder
2007-06-28 22:49 ` Daniel Jacobowitz
2007-06-28 23:12   ` msnyder
     [not found]   ` <655C3D4066B7954481633935A40BB36F041427@ussunex02.svl.access-company.com>
2007-06-29  0:24     ` Daniel Jacobowitz
2007-06-29  2:05       ` msnyder
2007-06-29 11:37         ` Daniel Jacobowitz
2007-06-29 17:02           ` Joel Brobecker
2007-06-29 20:34             ` Michael Snyder
2007-06-30 10:19           ` Michael Snyder
2007-06-30 14:17             ` Eli Zaretskii
2007-06-30 16:39               ` Michael Snyder [this message]
2007-06-30 16:40                 ` Daniel Jacobowitz
2007-06-30 18:25                 ` Eli Zaretskii
2007-07-03 18:13                   ` Jim Blandy
2007-07-04 17:35                     ` Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000b01c7bb2f$d88684e0$677ba8c0@sonic.net' \
    --to=msnyder@sonic.net \
    --cc=Michael.Snyder@access-company.com \
    --cc=drow@false.org \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox