Behaviour change for double-free'ing a pointer

[Joel Sherrill]

Tim Cussins wrote:
> Hi all, happy new year!
>   
Happy New Year!

Again this isn't necessarily a double free -- it could just
be a bogus address or even an offset from something
malloc'ed.
> 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.
>
>   
I have been refactoring the malloc family to make it more
pluggable pieces.  Being able to enable malloc statistics
and malloc dirty memory at confdefs.h time are two of the
benefits.  Making this a pluggable point is on my list. I
intend to give a couple of standard behaviors and then let
the user override. to provide their own.  Overkill but
the easiest way out of this one. 

Another side-effect of this work is to be able drop our the
call to sbrk and _Heap_Extend that is now part of every
application and rarely if ever actually needed.

This work is being done on my own volunteer time so
will be done when it is done. If anyone is interested
in it being completed, please email me privately.  I would
graciously accept some RTEMS Directed Development
sponsorship for this piece of important work.

--joel
> Cheers,
> Tim
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>