MISRA C rules 10.3 and 10.4

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

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

> Anyway, thanks for the interest to everyone.
> 
> Eirik
> 

John Devereux wrote:
> David Brown <david@westcontrol.removethisbit.com> writes:
> 
>> Hans-Bernhard Br&#4294967295;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?
> 

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

In article <46b9ac18$0$9939$8404b019@news.wineasy.se>, David Brown 
<david@westcontrol.removethisbit.com> writes
>Hans-Bernhard Br&#4294967295;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];
>
>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

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

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

"Chris Hills" <chris@phaedsys.org> wrote in message 
news:NddJ7CHUtbuGFAyv@phaedsys.demon.co.uk...
> In article <46b9ac18$0$9939$8404b019@news.wineasy.se>, David Brown 
> <david@westcontrol.removethisbit.com> writes
>>Hans-Bernhard Br&#4294967295;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];
>>
>>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
>
> 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

Are you not part of the MISRA-C team? 

John Devereux wrote:
> David Brown <david@westcontrol.removethisbit.com> writes:
>> John Devereux wrote:
>>> David Brown <david@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.

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

John Devereux wrote:
> David Brown <david@westcontrol.removethisbit.com> writes:
> 
>> John Devereux wrote:
>>> David Brown <david@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.
> 

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

Chris Hills wrote:
> In article <46b9ac18$0$9939$8404b019@news.wineasy.se>, David Brown 
> <david@westcontrol.removethisbit.com> writes
>> Hans-Bernhard Br&#4294967295;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];
>>
>> 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
> 
> 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
> 

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

In article <46b9d135$0$9937$8404b019@news.wineasy.se>, David Brown 
<david@westcontrol.removethisbit.com> writes
>Chris Hills wrote:
>> In article <46b9ac18$0$9939$8404b019@news.wineasy.se>, David Brown 
>><david@westcontrol.removethisbit.com> writes
>>> Hans-Bernhard Br&#4294967295;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];
>>>
>>> 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
>>  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
>>
>
>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.

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.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <NddJ7CHUtbuGFAyv@phaedsys.demon.co.uk>,
Chris Hills  <chris@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     |