Behaviour change for double-free'ing a pointer

Tim Cussins timcussins at eml.cc
Fri Jan 4 13:20:30 UTC 2008


Hi all, happy new year!

Firstly, I believe that if RTEMS is in a position to detect problems
with api parameters, then there should be a mechanism in place for the
failure to be flagged - for our purposes, where most debugging is done
over the network, printk's just aren't "in-your-face" enough. In this
case, assert(0) would suit us a bit better (dead device = motivation to
fix problem).

I've always understood assert(0) to imply a guaranteed halt: thanks to
Ralf I'm one step closer to true posix enlightenment - cheers! That
said, I think it's important that those reading code that uses assert()
understand the implications of flicking the NDEBUG switch: until now, I
would've incorrectly assumed that assert(0) would _always_ assert.

I would be happier with an explicit call instead of assert(0) in these
situations (ie double-free) - hopefully a call that invokes a
user-provided handler (or a default handler), or if not, then a call
that isn't subject to NDEBUG, so it's behaviour is more obvious when
reading the source.

Cheers,
Tim



More information about the users mailing list