+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C (https://forum.misra.org.uk/forumdisplay.php?fid=4)
+--- Forum: MISRA-C: 2004 rules (https://forum.misra.org.uk/forumdisplay.php?fid=17)
+---- Forum: 6.10 Arithmetic Type Conversions (https://forum.misra.org.uk/forumdisplay.php?fid=37)
+---- Thread: 10.3. Casting to a narrower type (/showthread.php?tid=285)
10.3. Casting to a narrower type - Hammer - 06-07-2006
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 - 23-08-2006
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.
Re: - eirik.midttun - 13-08-2007
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.embedded/browse_thread/thread/c8ffa9a92d2c15f7/c14a5bf85e2e9264#c14a5bf85e2e9264
- david ward - 14-08-2007
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 - 14-08-2007
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.
- misra-c - 26-09-2007
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.