change log for rtems (2010-07-26)

[Joel Sherrill]

On 07/26/2010 01:45 PM, Gedare Bloom wrote:
> On Mon, Jul 26, 2010 at 1:20 PM, Joel Sherrill
> <joel.sherrill at oarcorp.com>  wrote:
>    
>> On 07/26/2010 09:22 AM, Sebastian Huber wrote:
>>      
>>> On 07/26/2010 04:10 PM, rtems-vc at rtems.org wrote:
>>>
>>>        
>>>>   *joel*
>>>>
>>>> 2010-07-26      Joel Sherrill<joel.sherrilL at OARcorp.com>
>>>>
>>>>         * rtems/src/ratemonperiod.c: Use if not switch since all cases of
>>>> enum
>>>>         are not valid and switch was generating dead code.
>>>>
>>>>          
>>> I don't think that the following rule is useful:
>>>
>>> enum E {
>>>    A,
>>>    B,
>>>    C
>>> };
>>>
>>> Replace
>>>
>>> switch (e) {
>>>    case A:
>>>      a();
>>>      return S;
>>>    case B;
>>>      b();
>>>      return S;
>>>    case C:
>>>      break;
>>> }
>>> return -S;
>>>
>>> with
>>>
>>> if (e == A) {
>>>    a();
>>>    return S;
>>> }
>>> if (e == B) {
>>>    b();
>>>    return S;
>>> }
>>> return -S;
>>>
>>>
>>>        
>> Either code above would be OK IF C could
>> actually be generated.  But in the ratemonperiod.c
>> case, the values being eliminated can never occur
>> in this particular case.
>>
>> At Gedare's suggestion, I went back to the original
>> code and commented out the two cases that can't occur.
>> The dead code returned.
>>
>>      
> Do switch statements generate empty default stubs?  That might be the
> dead code here.  In which case we would need to provide a default
> case.
>
>    
Yes. Usually.  And if you are covering all the values explicitly
this results in an unreachable path.
>> This is a coverage issue and since all of the cases
>> return, I think it actually looks better as an if.
>>
>>      
> I actually also prefer the if statements in this situation, since the
> switch statement in ratemonperiod was nested anyway.
>
>    
It was nested deeper than I personally like.  Plus it lets
us favor the order in which the states are checked.
>> Any other ideas to try?  I am open to any coding suggestions
>> as long as they don't introduce dead code.
>>
>> Index: ratemonperiod.c
>> ===================================================================
>> RCS file: /usr1/CVS/rtems/cpukit/rtems/src/ratemonperiod.c,v
>> retrieving revision 1.27
>> diff -u -r1.27 ratemonperiod.c
>> --- ratemonperiod.c    15 Dec 2009 18:26:41 -0000    1.27
>> +++ ratemonperiod.c    26 Jul 2010 17:19:00 -0000
>> @@ -360,12 +360,14 @@
>>            _Thread_Enable_dispatch();
>>            return RTEMS_TIMEOUT;
>>
>> +#if 0
>>          case RATE_MONOTONIC_OWNER_IS_BLOCKING:
>>          case RATE_MONOTONIC_EXPIRED_WHILE_BLOCKING:
>>            /*
>>             *  These should never happen.
>>             */
>>            break;
>> +#endif
>>        }
>>
>>   #if defined(RTEMS_MULTIPROCESSING)
>>
>>
>> --
>> 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
>>
>>
>> _______________________________________________
>> rtems-vc mailing list
>> rtems-vc at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-vc
>>
>>      


-- 
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