change log for rtems (2010-07-26)

Gedare Bloom gedare at gwmail.gwu.edu
Mon Jul 26 18:45:17 UTC 2010


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.

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

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




More information about the vc mailing list