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.

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

Reply to
Eirik Midttun
Loading thread data ...

In article , Eirik Midttun writes

Ask in the MISRA-c forum

formatting link

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     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

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.

Reply to
David Brown

Hi Eirik,

Have a look at this,

formatting link

Dave

Reply to
dathome

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)?
Reply to
David Brown

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.

Reply to
Hans-Bernhard Bröker

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

R.

Reply to
Richard Phillips

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

Reply to
Eirik Midttun

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

--

John Devereux
Reply to
John Devereux

[...]

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

--

John Devereux
Reply to
John Devereux

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];

This is banned, not because "u16a + 1" might overflow or be outside the array bounds, but because the array lookup is "complex".

Perhaps there is no good, clear formulation that would ban the possibly incorrect expressions but not legitimate ones.

mvh.,

David

Reply to
David Brown

I misread the pdf - the array lookup is on the "non-complex" side, not the "complex" side.

Reply to
David Brown

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

Reply to
David Brown

If you lot had this discussion of the MISRA-C forum then the MISRA-C team would see it and take note of it.

See

formatting link

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

Are you not part of the MISRA-C team?

Reply to
Tom Lucas

Since, as a general rule, a cast is probably an error, I think this is more than just a style.

--
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
Reply to
CBFalconer

It's all about readability - if the casts make it clearer what your code is doing (or why), then use them. If not, then they become noise, and reduce readability.

Of course, it's often best to reduce the need for casting whenever possible.

mvh.,

David

Reply to
David Brown

Yes, but then others in c.a.e. (except where they overlap) would not have seen the discussion - here we are getting a general view on such casts, rather than a specific MISRA-oriented view. Also many people, such as myself, find web forums a serious pain - newsgroups (and mailing lists) are much better for many types of discussion.

If we had discovered a serious problem with MISRA, then it would make sense to tell the MISRA team (though that's not really needed, since you are on the team yourself).

Reply to
David Brown

It can be a general view in the MISRa -forum... the difference being the MISRA Team see it too.

That's good for you.

Yes.

Why should I spend a lot of time transposing this lot onto another system because you can't be bothered?

I do copy some things across occasionally.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

Reasonable idea, on first glance. But then I see it's a web forum. YUCK! Web forums are *the* WORST form of online communication out there. No way am I wasting my time with that...

Either a newsgroup (hosted from anywhere, it doesn't have to be part of the Usenet hierarchy) or a maillist would be a much better -- efficient and effective -- communications mechanism.

--
  /"\  ASCII Ribbon Campaign   |
  \ /                          |   Email to user 'CTZ001'
 Click to see the full signature
Reply to
Tom Ziomek

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.