NULL call to _Workspace_Free() via _Objects_Extend_information at startup

[Joel Sherrill]

On 03/01/2011 02:56 AM, Sebastian Huber wrote:
> On 03/01/2011 09:50 AM, Peter Dufault wrote:
>> I'm not sure the requirement that "_Heap_Free(heap, NULL)" be ignored makes much sense.
> It makes sense in a way that _Heap_Free() accepts in this case all values
> returned by _Heap_Allocate_*().
>
Remember what  Sebastian and I were doing when we found this
under the rock.  There were multiple cases in RTEMS APIs and
score where "if p _Workspace_Free(p)"  My driving force was
simplicity and branch patch complexity.  Moving the "if null"
from multiple places to _Workspace_Free, simplified the code,
reduced the number of needed test cases. and ensured that
NULL would never slip by _Workspace_Free and accidentally
get passed to the heap code.  When Sebastian removed the
NULL check from _Workspace_Free, he removed the final curtain
that exposed the protection code using a pointer before validated.

For Chris to fail, I am guessing he is building with debug enabled
and I am not.  But in either case, the heap has to be careful not
to use a pointer before validating it.

I think accepting NULL as input and returning true is the best
solution.  And validating pointers before the protection code
gets to run is an absolute necessity.  It may even make sense
to validate block and next before checking the protection.

FWIW free() never called _Workspace_Free, it always called _Heap_Free
directly so this had no impact.


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985