[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Behaviour change for double-free'ing a pointer
- Date: Thu, 20 Dec 2007 10:45:56 -0800
- From: aaron at frye.com (Aaron J. Grier)
- Subject: Behaviour change for double-free'ing a pointer
On Wed, Dec 19, 2007 at 02:44:15PM -0600, Joel Sherrill wrote:
> This begs a bigger question... should RTEMS assert at all?
it raises the question, but doesn't beg it. begging the question would
be claiming that RTEMS should assert because it already does.
> Most of the asserts I have analyzed over the past couple of months
> cannot occur unless there is a data corruption problem or problem with
> the RTEMS internal logic. Those are being marked with RTEMS_DEBUG
> conditionals. Otherwise they are untestable dead code.
> Should it be possible for RTEMS provided code to halt at run-time?
assuming RTEMS doesn't have internal logic problems (=, what should
RTEMS do in the case of data corruption? for my application, dropping
back to a bootloader and reloading the system is the safest thing to do,
so assert() is fine for me. others may have more complicated
error-recovery mechanisms, so compile with -DNDEBUG. it really depends
on the application, and in the embedded world, there seems to be an
exception for every rule-of-thumb.
I believe it should be possible and optional for RTEMS to halt at
Aaron J. Grier | Frye Electronics, Tigard, OR | aaron at frye.com