From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: "Frank Ch. Eigler" Cc: gdb-patches@sources.redhat.com Subject: Re: Simple but crucial bug fix to gdb Date: Wed, 06 Jun 2001 06:01:00 -0000 Message-id: <3B1E29AC.2030807@cygnus.com> References: <3.0.5.32.20010530142745.01470ec0@pophost.pdxuxbre.lmc.com> <20010530173650.A21397@redhat.com> <3B15711D.BEA4B77E@cygnus.com> <3B1638A2.79AE4BCF@redhat.com> <20010531194656.A27403@redhat.com> <87ofs9hw29.fsf@dynamic-addr-83-177.resnet.rochester.edu> X-SW-Source: 2001-06/msg00053.html > Daniel Berlin 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