change log for rtems (2010-07-26)
Joel Sherrill
joel.sherrill at OARcorp.com
Mon Jul 26 18:48:30 UTC 2010
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
More information about the vc
mailing list