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 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.
misra-c Wrote: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
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.
Original question at comp.arch.embedded:
Quote: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:
Quote:> 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.
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.