This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]