This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
asert(); Was: RFC: internal_error() change + abort()
Mark Kettenis wrote:
>
> Date: Mon, 24 Jul 2000 20:20:00 +1000
> From: Andrew Cagney <ac131313@cygnus.com>
>
> Yes, the one remaining abort() call would be in internal_error().
>
> As a generalization, GDB should never abort. The last thing you want is
> your complext debug session to be terminated by the debugger dumping
> core :-(
>
> Somewhat related to this subject, here's a replacement for assert() I
> hacked up a few weaks ago. It's modelled after the assert() in the
> GNU C Library, and very useful since I cannot quit the habit of
> littering my code with assertions :-)
The idea of assertions doesn't worry me - I tend to use them myself.
sim/* is littered with them.
Several thoughts though.
> +#if !defined (GDB_ASSERT_H)
> +#define GDB_ASSERT_H
> +
> +#undef assert
> +#undef assert_perror
> +
> +#define assert(expr) \
> + ((void) ((expr) ? 0 : \
> + (assert_fail (#expr, __FILE__, __LINE__, ASSERT_FUNCTION), 0)))
Redefining the system assert() gives me cold feet. I'd rather see
something like ``GDB_ASSERT()'' so that it is clear that this isn't a
standard assert with standard behavour.
Is the extra level of macros with ``assert_fail()'' needed?
There wouldn't be a pre-existing libiberty/xassert.h?
> +
> +#define assert_perror(errnum) \
> + ((void) (!(errnum) ? 0 : (assert_perror_fail ((errnum), \
> + __FILE__, __LINE__, \
> + ASSERT_FUNCTION), 0)))
Is this one useful? As good programmers, we always check the return
status and take evasive action when the syscall fails, right? :-^.
enjoy,
Andrew