[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
NULL call to _Workspace_Free() via _Objects_Extend_information at startup
- Date: Tue, 1 Mar 2011 03:50:11 -0500
- From: dufault at hda.com (Peter Dufault)
- Subject: NULL call to _Workspace_Free() via _Objects_Extend_information at startup
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.
HD Associates, Inc. Software and System Engineering