[PATCH 15/20] chainimpl.h: Add _Assert() to _Chain_Initialize_empty()

[Gedare Bloom]

On Wed, Nov 26, 2014 at 12:32 PM, Peter Dufault <dufault at hda.com> wrote:
>
>> On Nov 26, 2014, at 11:40 , Gedare Bloom <gedare at rtems.org> wrote:
>>
>> What is the difference between the previous two variants? Would you
>> expect to optimize out "Assert_known" in all production code?
>>
>
> "Assert_known_not_NULL" implies that either someone broke the code (the known assertion no longer applies due to a new bug) or that there is memory corruption (a previously asserted non-NULL pointer is now NULL).  This should never be optimized away - you want to know that this has happened, something is really, really wrong.
>
This would be a specific version of an assert that would not get
compiled-away then. I'm not sure if we want to include such a class of
asserts or not. I would like to see RTEMS support for different ways
to use asserts improve (e.g. wrappers for overriding the libc handling
of assert i.e. puke or do something else, ability to keep asserts but
not other debug stmts, etc).

> "Assert_not_NULL" implies laziness (or expedience?) in production code.  The call chain down to the asserting function hasn't been analyzed to know that a passed in pointer is not NULL, and all you want to do today is shutdown if the passed-in pointer is NULL.
>
I guess the difference is whether the assert implies a local
assumption (I require this var is not NULL) or a global one (This var
has been previously verified to be not NULL). It may be worth
classifying asserts in those two categories.

-Gedare

> Both situations require a fail-safe shutdown but you want to know that the first happened.  The second can be handled in an exception by de-referencing low memory, the first needs to be treated more seriously.
>
> They should be handled differently because the first is so much worse than the second.
>
> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
>