10.3. Casting to a narrower type

[Hammer]

Code:

(int16_t)(s32a * s32b) /*Compliant */

This example is found on page 45.

I would like clarification on how this can be compliant code without having to check whether the result of s32*s32 can fit into a short. is my understanding correct that the multiplication will take place as int32_t and then be casted to int16_t.

I would be grateful for some clarification on the topic.

[misra-c]

MISRA-C meeting 23-8-2006.

Code:

s16c = (int16_t)(s32a * s32b);

Having made the cast explicit, it is still necessary to be sure that the cast results in no loss of infomation.

The cast makes it clear this is a 16 bit constraint.

Implicit narrowing casts are prohibited by 10.1.

[eirik.midttun]

MISRA-C meeting 23-8-2006.

Is there any minutes available from this meeting? Or could you offer a more in-depth rational?

I posted a question on rule 10.3 and 10.4 on comp.arch.embedded and nobody could come up with a good explaination. Link to thread:
http://groups.google.com/group/comp.arch...f85e2e9264

[david ward]

The date is there for reference of when this issue was reviewed - there are no minutes as such but questions reviewed by the MISRA C Working Group are posted with an official reply (from the \"misra-c\" user).

If you could repost your question here it would be helpful and the MISRA C Group will give an official reply in due course. You might also find the MISRA C Technical Corrigendum (accessible in the \"Resources\" section to registered users of this forum) useful.

[eirik.midttun]

Original question at comp.arch.embedded:

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.



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?

Best answer so far:

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

But in general people, me included, seems puzzled by this rule.

[misra-c]

10.3 and 10.4 do apply to explicit casts. They are in the section 6.10.7 entitled \"Explicit conversions (casts)\".

Therefore the example above clearly illustrates the intent of MISRA-C and is correct in its reasoning.