This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Simple but crucial bug fix to gdb
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Subject: Re: Simple but crucial bug fix to gdb
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 06 Jun 2001 09:01:32 -0400
- Cc: gdb-patches at sources dot redhat dot com
- References: <3.0.5.32.20010530142745.01470ec0@pophost.pdxuxbre.lmc.com> <20010530173650.A21397@redhat.com> <3B15711D.BEA4B77E@cygnus.com> <npvgmimcih.fsf@zwingli.cygnus.com> <3B1638A2.79AE4BCF@redhat.com> <npelt5me4f.fsf@zwingli.cygnus.com> <20010531194656.A27403@redhat.com> <87ofs9hw29.fsf@dynamic-addr-83-177.resnet.rochester.edu> <o57kywdhvp.fsf@touchme.toronto.redhat.com>
> Daniel Berlin <dan@cgsoftware.com> writes:
>
> : [...]
> : However, we should *never* see a case where pst is NULL, and
> : textlow_not_set is 1, at the point we see a function.
> : [...]
>
> Would a gdb_assert() to this effect satisfy all sides?
>
> - FChE
Yes.
gdb_assert() and internal_error() are for reporting problems internal to
gdb. EG: a check for a NULL reference caused by GDB failing to
detect/handle bad input. Both of these functions force GDB to abandon
the current command.
warning() and error() should only be used when the problem is caused by
an external interface/input _and_ GDB correctly recovered. EG: a
warning() to notify the user that a file is corrupt but GDB has managed
to recover from the problem. You migt even end up with:
if (recovery case 1)
warning (...); recover;
else if (recovery case 2)
warning (...); recover;
else
internal_error (oops, stuffed);
The difference is subtle but important. I'd only think about replacing
gdb_assert() / internal_error() with warning() / error() when it is
clear that the problem isn't internal to GDB and that GDB is correctly
recovering from it.
Andrew