change log for rtems (2010-06-24)

[Joel Sherrill]

On 06/25/2010 02:35 AM, Ralf Corsepius wrote:
> On 06/25/2010 09:19 AM, Chris Johns wrote:
>    
>> On 25/06/10 5:10 PM, Ralf Corsepius wrote:
>>      
>>>>>            
>>>> I don't think that this explosion of ifdef is good.
>>>>          
>>> ACK.
>>>        
>>>> Why not add a
>>>> rtems_assert() which is defined in case of RTEMS_DEBUG?
>>>>
>>>>          
>>> Why? Haven't you guys heard about NDEBUG?
>>>
>>> All these defines are superfluous.
>>>
>>>        
>> The only issue with NDEBUG is the interaction with an application. If
>> a user uses NDEBUG in an application what happens to RTEMS includes
>> etc if RTEMS is not built with NDEBUG ?
>>      
> You are outsmarting yourself.
> * newlib and the gcclibs all are built without NDEBUG.
> * compiling RTEMS with -DNDEBUG is a micro-optimization only affecting RTEMS
>
> * assert.h is guaranteed to be present. Conditionally including assert.h
> doesn't buy you anything.
>
>    
And using assert for sanity checks that can never
occur from the programming interface adds dead
code and unreachable paths which are untestable.

Having a way to conditionalize this internal sanity
checking code is important.  When people modify
RTEMS and break something, these checks become
useful.  But in a production system, they are not
useful and are in fact hindrances to testability.
>    
>> A single common method in RTEMS would be nice and I do not care much
>> what it is. All I ask is it being controlled by configure's
>> --enable-debug.
>>      
> --enable-debug is supposed to enable some internal debug aids. It is not
> supposed to interact with NDEBUG.
>
>    
Correct.  And these are sanity checks that cannot happen
in a production system via the APIs.
> Ralf
>
>
> _______________________________________________
> rtems-vc mailing list
> rtems-vc at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-vc
>