This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: RFA: top.c: new catch_errors + cleanup interface
- To: ac131313 at cygnus dot com
- Subject: Re: RFA: top.c: new catch_errors + cleanup interface
- From: "Nick Duffek <Nick Duffek"<nsd at cygnus dot com>
- Date: Thu, 13 Apr 2000 18:24:00 GMT
- CC: gdb-patches at sourceware dot cygnus dot com
- References: <38F564D1.FAB2CEEC@cygnus.com>
On 13-Apr-2000, Andrew Cagney wrote:
>Given the above and knowing that, longer term, GDB is ment to be trying
>to get away from all this long-jumping stuff
Oh, I didn't realize. Should we be avoiding the use of error() in favor
of warning() + return values?
>I've real reservations about any change that on the
>surface makes using the catch_errors() easier
By the same token, though, a simpler interface would make it easier to
switch to a return-value-based paradigm in the future.
>you could see what it was doing as it didn't involve complex multi-line
>macros.
Would it make the patch more acceptable if I reduced the macro complexity?
For example, the following interface:
struct catch_context cctx;
...
if (CATCH_BEGIN (&cctx, <msg>, <mask>))
{
... code that might return nonlocally ...
}
catch_cleanup (&cctx);
... code that always gets executed ...
catch_end (&cctx);
would be implemented like this:
#define CATCH_BEGIN(context, errstr, mask) \
(catch_begin (context, errstr, mask), \
!((context)->caught = CATCH_SETJMP ((context)->catch)))
Another possible version of the interface doesn't use macros at all, aside
from CATCH_SETJMP or something similar to hide arch dependencies:
struct catch_context cctx;
...
catch_begin (&cctx, errstr, mask);
cctx.caught = CATCH_SETJMP (cctx.catch);
if (!cctx.caught)
{
... code that might return nonlocally ...
}
catch_cleanup (&cctx);
... code that always gets executed ...
catch_end (&cctx);
Nick