MISRA C rules 10.3 and 10.4

Hi,

In MISRA-C 2004:
Rule 10.4:
The value of a complex expression of integer type may only be cast to
a type that is narrower and of the same signedness as the underlying
type of the expression.

Rule 10.3:
The value of a complex expression of floating type may only be cast to
a type that is narrower floating type.

</quote>

So why should the cast be more narrow? The Guidelines gives a
reference to section 6.10, but don't offer much insight. The only
consequence I see is that the result potentially missing the most
significant bits.

Anyone who cares to enlighten me?

Eirik

In article <1186491843.568863.116770@19g2000hsx.googlegroups.com>, Eirik 
Midttun <emidttun@gmail.com> writes
>Hi,
>
>In MISRA-C 2004:
>Rule 10.4:
>The value of a complex expression of integer type may only be cast to
>a type that is narrower and of the same signedness as the underlying
>type of the expression.
>
>Rule 10.3:
>The value of a complex expression of floating type may only be cast to
>a type that is narrower floating type.
>
></quote>
>
>So why should the cast be more narrow? The Guidelines gives a
>reference to section 6.10, but don't offer much insight. The only
>consequence I see is that the result potentially missing the most
>significant bits.
>
>Anyone who cares to enlighten me?
>
>Eirik

Ask in the MISRA-c forum   www.misra-c.com

There is some one there who will give you chapter and verse.... probably 
far more than you ever wanted to know :-)

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills wrote:
> In article <1186491843.568863.116770@19g2000hsx.googlegroups.com>, Eirik 
> Midttun <emidttun@gmail.com> writes
>> Hi,
>>
>> In MISRA-C 2004:
>> Rule 10.4:
>> The value of a complex expression of integer type may only be cast to
>> a type that is narrower and of the same signedness as the underlying
>> type of the expression.
>>
>> Rule 10.3:
>> The value of a complex expression of floating type may only be cast to
>> a type that is narrower floating type.
>>
>> </quote>
>>
>> So why should the cast be more narrow? The Guidelines gives a
>> reference to section 6.10, but don't offer much insight. The only
>> consequence I see is that the result potentially missing the most
>> significant bits.
>>
>> Anyone who cares to enlighten me?
>>
>> Eirik
> 
> Ask in the MISRA-c forum   www.misra-c.com
> 
> There is some one there who will give you chapter and verse.... probably 
> far more than you ever wanted to know :-)
> 

Yes, but now others here (or at least me!) are curious about such a 
strange rule - normally it is considered safe to cast to a wider type, 
and unsafe to cast to a narrower type.

"Eirik Midttun" <emidttun@gmail.com> wrote in message 
news:1186491843.568863.116770@19g2000hsx.googlegroups.com...
> Hi,
>
> In MISRA-C 2004:
> Rule 10.4:
> The value of a complex expression of integer type may only be cast to
> a type that is narrower and of the same signedness as the underlying
> type of the expression.
>
> Rule 10.3:
> The value of a complex expression of floating type may only be cast to
> a type that is narrower floating type.
>
> </quote>
>
> So why should the cast be more narrow? The Guidelines gives a
> reference to section 6.10, but don't offer much insight. The only
> consequence I see is that the result potentially missing the most
> significant bits.
>
> Anyone who cares to enlighten me?
>
> Eirik
>

Hi Eirik,

Have a look at this,

http://www.misra-c.com/downloads/MC2004-Burden.pdf

Dave 

dathome wrote:
> "Eirik Midttun" <emidttun@gmail.com> wrote in message 
> news:1186491843.568863.116770@19g2000hsx.googlegroups.com...
>> Hi,
>>
>> In MISRA-C 2004:
>> Rule 10.4:
>> The value of a complex expression of integer type may only be cast to
>> a type that is narrower and of the same signedness as the underlying
>> type of the expression.
>>
>> Rule 10.3:
>> The value of a complex expression of floating type may only be cast to
>> a type that is narrower floating type.
>>
>> </quote>
>>
>> So why should the cast be more narrow? The Guidelines gives a
>> reference to section 6.10, but don't offer much insight. The only
>> consequence I see is that the result potentially missing the most
>> significant bits.
>>
>> Anyone who cares to enlighten me?
>>
>> Eirik
>>
> 
> Hi Eirik,
> 
> Have a look at this,
> 
> http://www.misra-c.com/downloads/MC2004-Burden.pdf
> 
> Dave 
> 

If the emphasis had been on explicit casting, it would have made sense - 
"the value may only be *explicitly cast* to a type that is narrower, not 
implicitly", then it would have made sense.  But (according to the above 
link), Misra-C allows:

u16x = (U16)(u32a + u32b);

but not:

u32x = (U32)(u16a + u16b);

To store the results of (u16a + u16b) to u32x, you must first introduce 
a temporary u16 variable to store the results of the sum, then cast it 
(implicitly or explicitly) to u32x.

Is this perhaps to avoid possible confusion regarding overflows (i.e., 
someone might think if u16a and u16b were both 50000 then u32x would be 
100000)?

David Brown wrote:
> If the emphasis had been on explicit casting, it would have made sense - 
> "the value may only be *explicitly cast* to a type that is narrower, not 
> implicitly", then it would have made sense.  But (according to the above 
> link), Misra-C allows:
> 
> u16x = (U16)(u32a + u32b);
> 
> but not:
> 
> u32x = (U32)(u16a + u16b);

If so, that's quite positive achievement.  Too many people believe that
	
	u16a = 40000;
	u16b = 40000;
	u32x = (U32)(u16a + u16b);
	
will end up with u32x = 80000.  If MISRA can invent rules that trigger 
on precisely this case and convince those people to write what they 
actually wanted:

	u32x = (U32) u16a + (U32) u16b;

that would be a very good thing indeed.

Hans-Bernhard Br�ker wrote:
> David Brown wrote:
>> If the emphasis had been on explicit casting, it would have made
>> sense - "the value may only be *explicitly cast* to a type that is
>> narrower, not implicitly", then it would have made sense.  But
>> (according to the above link), Misra-C allows:
>>
>> u16x = (U16)(u32a + u32b);
>>
>> but not:
>>
>> u32x = (U32)(u16a + u16b);
>
> If so, that's quite positive achievement.  Too many people believe
> that
> u16a = 40000;
> u16b = 40000;
> u32x = (U32)(u16a + u16b);
>
> will end up with u32x = 80000.  If MISRA can invent rules that trigger
> on precisely this case and convince those people to write what they
> actually wanted:
>
> u32x = (U32) u16a + (U32) u16b;
>
> that would be a very good thing indeed.

Yup, "cast then add", rather than "add (then overflow) then cast"!

R. 

On Aug 8, 2:09 pm, David Brown <da...@westcontrol.removethisbit.com>
wrote:

> u32x = (U32) u16array[u16a + 1];
>
> This is banned, not because "u16a + 1" might overflow or be outside the
> array bounds, but because the array lookup is "complex".

The expression is in fact _not_ complex because what you cast to
uint32 is not a result of an arithmetic operation. There is a similar
example in the MISRA-C guidelines.

Anyway, thanks for the interest to everyone.

Eirik

David Brown <david@westcontrol.removethisbit.com> writes:

> Hans-Bernhard Br&#4294967295;ker wrote:
>> David Brown wrote:
>>> If the emphasis had been on explicit casting, it would have made
>>> sense - "the value may only be *explicitly cast* to a type that is
>>> narrower, not implicitly", then it would have made sense.  But
>>> (according to the above link), Misra-C allows:
>>>
>>> u16x = (U16)(u32a + u32b);
>>>
>>> but not:
>>>
>>> u32x = (U32)(u16a + u16b);
>>
>> If so, that's quite positive achievement.  Too many people believe that
>>         u16a = 40000;
>>     u16b = 40000;
>>     u32x = (U32)(u16a + u16b);
>>     will end up with u32x = 80000.  If MISRA can invent rules that
>> trigger on precisely this case and convince those people to write
>> what they actually wanted:
>>
>>     u32x = (U32) u16a + (U32) u16b;
>>
>> that would be a very good thing indeed.
>>
>
> Rules that avoid such mistakes are good, it's true.  However, this
> particular rule also disallows many other expressions that are
> perfectly reasonable:
>
> u32x = (U32) u16array[u16a + 1];

But these sort of explicit casts (narrower-to-wider) are redundant,
aren't they?

-- 

John Devereux

David Brown <david@westcontrol.removethisbit.com> writes:

> John Devereux wrote:
>> David Brown <david@westcontrol.removethisbit.com> writes:

[...]

>>> Rules that avoid such mistakes are good, it's true.  However, this
>>> particular rule also disallows many other expressions that are
>>> perfectly reasonable:
>>>
>>> u32x = (U32) u16array[u16a + 1];
>>
>> But these sort of explicit casts (narrower-to-wider) are redundant,
>> aren't they?
>>
>
> They are redundant to the compiler (they will be implicitly cast), but
> are not necessarily redundant to the programmer and others who read
> the code - if they make the code clearer, they are useful ("explicit
> is better than implicit").

OK - a matter of style I suppose. I prefer to avoid casts where
possible.

-- 

John Devereux