MISRA C rules 10.3 and 10.4
Eirik Midttun
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
Chris Hills
Midttun <emid...@gmail.com> writes
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 /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
David Brown
> In article <1186491843.5...@19g2000hsx.googlegroups.com>, Eirik
> Midttun <emid...@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.
dathome
"Eirik Midttun" <emid...@gmail.com> wrote in message
news:1186491843.5...@19g2000hsx.googlegroups.com...
Hi Eirik,
Have a look at this,
http://www.misra-c.com/downloads/MC2004-Burden.pdf
Dave
David Brown
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)?
Hans-Bernhard Bröker
> 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.
Richard Phillips
Yup, "cast then add", rather than "add (then overflow) then cast"!
R.
David Brown
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
Eirik Midttun
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
John Devereux
> 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.
>>
>
> 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
> 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.
>
I misread the pdf - the array lookup is on the "non-complex" side, not
the "complex" side.
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").
John Devereux
> John Devereux wrote:
>> David Brown <da...@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
Chris Hills
<da...@westcontrol.removethisbit.com> writes
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 www.misra-c.com
Tom Lucas
news:NddJ7CHU...@phaedsys.demon.co.uk...
Are you not part of the MISRA-C team?
David Brown
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
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).
CBFalconer
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.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
Chris Hills
It can be a general view in the MISRa -forum... the difference being the
MISRA Team see it too.
> Also many people, such as myself, find web forums a serious pain -
>newsgroups (and mailing lists) are much better for many types of
>discussion.
That's good for you.
>If we had discovered a serious problem with MISRA, then it would make
>sense to tell the MISRA team
Yes.
>(though that's not really needed, since you are on the team yourself).
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.
David Brown
It's also good for the original poster - the discussion is held in a
place that suits him. If he (or others) are looking for more expert
help, then of course they must go where the experts hang out - i.e., the
MISRA forums.
>
>> If we had discovered a serious problem with MISRA, then it would make
>> sense to tell the MISRA team
>
> Yes.
>
>> (though that's not really needed, since you are on the team yourself).
>
> Why should I spend a lot of time transposing this lot onto another
> system because you can't be bothered?
>
If this thread had found something important and relevant to MISRA, then
you should spend that time - because MISRA is important to *you*. MISRA
is of no importance to *me* - this thread is just an excuse to think
about C coding and style rules that are of interest to embedded
programming in general. So if something relevant to the MISRA team had
come up, then why should *I* spend time telling them? I would already
know about the problem, as would the original poster, and the others in
the thread - why should I then spend extra time helping an unrelated (to
me) commercial group do their job?
In actual practice, if I had found something worth bothering the MISRA
team about, then I would have told them (assuming you didn't), just
because I think it might help other people. But I don't think it's
appropriate for you to imply that I have some sort of duty to spend
extra effort passing information on to anyone. It would be a different
matter if I were using MISRA's work, of course.
CBFalconer
>
>> If we had discovered a serious problem with MISRA, then it would
>> make sense to tell the MISRA team
>
> Yes.
>
>> (though that's not really needed, since you are on the team
>> yourself).
>
> Why should I spend a lot of time transposing this lot onto
> another system because you can't be bothered?
Sounds like a rather foul attitude. I hope I am mistaken.
Richard Phillips
Chris,
To be fair here, I don't think anyone expects you to transpose this lot onto
another system, however there is no reason why you can't take on board (as a
MISRA representative) any relevant points/problems raised. I think that was
David Brown's message!
Regards,
Richard.
Eirik Midttun
> Hi Eirik,
>
> Have a look at this,
>
> http://www.misra-c.com/downloads/MC2004-Burden.pdf
>
> Dave
Thanks, just read through it. It is somewhat clarifying.
It says on page 13 that type conversions should be avoided, something
I agree on, and that temporary variables might be required. I can see
a problem with for example this expression:
(uint32_t) (u16a + u16b)
If the complex overflows this cast is not helping one bit, but can on
the contrary lead you to think there is no problem.
Chris Hills
<raphi...@ntlworld.com> writes
I do tend to cut and past stuff across.
Tom Ziomek
Chris Hills <ch...@phaedsys.demon.co.uk> wrote:
>
>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 www.misra-c.com
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'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
Tom Ziomek
Chris Hills <ch...@phaedsys.demon.co.uk> wrote:
>
>Why should I spend a lot of time transposing this lot onto another
>system because you can't be bothered?
Well, that sentiment can cut both ways. Why should we spend a lot of
time (most of it non-productive) mucking with a web forum because MISRA
can't be bothered to use anything better than a lowest common denomina-
tor communications mechanism?
Chris Hills
<zio...@gauley.ddna.labs.mot.com> writes
>In article <NddJ7CHU...@phaedsys.demon.co.uk>,
>Chris Hills <ch...@phaedsys.demon.co.uk> wrote:
>>
>>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 www.misra-c.com
>
>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.
I can;t disagree but it is the way of the world
>No way am I wasting my time with that...
Your choice
>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.
Probably.
Everett M. Greene
> John Devereux wrote:
> > David Brown <da...@westcontrol.removethisbit.com> writes:
> >> John Devereux wrote:
> >>> David Brown <da...@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.
>
> Since, as a general rule, a cast is probably an error, I think this
> is more than just a style.
Being a bit extreme, aren't we? Have you ever tried writing the
support functions for C without using casts? It's difficult to
do very much with void * arguments without casting them to
something.
CBFalconer
> CBFalconer <cbfal...@yahoo.com> writes:
>
... snip ...
>>
>> Since, as a general rule, a cast is probably an error, I think this
>> is more than just a style.
>
> Being a bit extreme, aren't we? Have you ever tried writing the
> support functions for C without using casts? It's difficult to
> do very much with void * arguments without casting them to something.
The thing to do with void* arguments is to copy them to known
pointer types. No casts are needed for this, and the compiler can
check everything properly. When you cast you are overriding the
compilers error messages and warnings. For example:
void memcopy(void *from, void *to, size_t lgh) {
unsigned char *f = from, *t = to;
if (from && to)
while (lgh--) *t++ = *f++;
Colin Paul Gloster
18:58:24 +0000 (UTC), zio...@gauley.ddna.labs.mot.com (Tom Ziomek)
posted:
|-----------------------------------------------------------------------|
|"[..] |
| |
|[..] MISRA |
|can't be bothered to use anything better than a lowest common denomina-|
|tor communications mechanism? |
| |
|-- |
| /"\ ASCII Ribbon Campaign | |
| \ / | Email to user 'CTZ001' |
| X Against HTML | at 'email.mot.com' |
| / \ in e-mail & news |" |
What is ASCII if not "a lowest common denomina-tor communications mechanism"?
Eirik Midttun
> 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
>
> > 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);
>
> 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.
I posted this reply on MISRA-Cs forum because it was the best answer I
could find in the thread. They have now answered:
"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."
So I think that will conclude the discussion. Thanks for the
contributions everyone.
- Eirik