NULL call to _Workspace_Free() via _Objects_Extend_information at startup

[Peter Dufault]

On Mar 1, 2011, at 3:19 , Sebastian Huber wrote:

>> 
>> _Heap_Block_size(block), _Heap_is_free(block), _Heap_is_block_in_heap(const Heap_Control *heap, const Heap_Block *block).
>> 
>> Ideally the definition should be derived from a concise definition of what a NULL heap block pointer means, and those operations that are undefined should be specified as undefined.
>> 
>> One could argue that _Heap_Block_size(0) == 0, _Heap_is_free(0) == true, _Heap_is_block_in_heap(0, *) == true.  I'm not arguing it, though, since I'm not presenting the "concise definition" I mention above.
> 
> These are all internal heap functions.  They must work only with pointers to an
> allocated area.

Anything with a leading underscore is by definition an internal function to RTEMS, including _Heap_Free().  Leading underscore is a reserved name space for the OS.

One advantage of malloc() / free() / realloc() is that the NULL pointer usage is consistent. Because of the existing design (_Heap_Block_allocate() takes a Heap_Block * not a Heap_Block **) I'm not sure the requirement that "_Heap_Free(heap, NULL)" be ignored makes much sense.  You can't start out with a Heap_Block * of NULL and pass it to Heap_Block functions and have it do the right thing.  The crash in Workspace_Free() was a pointer-punning problem.

That said, I guess for legacy reasons just define that _Heap_Free(*, 0) returns OK, and that passing 0 anywhere else is undefined.

Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering