In article <BoTaWtAvafuGFAQk@phaedsys.demon.co.uk>, Chris Hills <chris@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? -- /"\ ASCII Ribbon Campaign | \ / | Email to user 'CTZ001' X Against HTML | at 'email.mot.com' / \ in e-mail & news |
MISRA C rules 10.3 and 10.4
Started by ●August 7, 2007
Reply by ●August 8, 20072007-08-08
Reply by ●August 8, 20072007-08-08
Chris Hills wrote:> 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�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.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.> I do copy some things across occasionally. > >
Reply by ●August 8, 20072007-08-08
Chris Hills wrote:> David Brown <david@westcontrol.removethisbit.com> writes >... snip ...> >> 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. -- 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
Reply by ●August 9, 20072007-08-09
Chris Hills wrote:> 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�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, 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.
Reply by ●August 9, 20072007-08-09
On Aug 8, 11:56 am, "dathome" <d...@home.com> wrote:> Hi Eirik, > > Have a look at this, > > http://www.misra-c.com/downloads/MC2004-Burden.pdf > > DaveThanks, 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.
Reply by ●August 9, 20072007-08-09
In article <f9egt1$h57$1@aioe.org>, Richard Phillips <raphillips@ntlworld.com> writes>Chris Hills wrote: >> 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�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, >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!I do tend to cut and past stuff across. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●August 9, 20072007-08-09
In article <f9d375$1ng$1@engnntp2.cig.mot.com>, Tom Ziomek <ziomek@gauley.ddna.labs.mot.com> writes>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.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. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●August 9, 20072007-08-09
CBFalconer <cbfalconer@yahoo.com> writes:> 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.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.
Reply by ●August 9, 20072007-08-09
"Everett M. Greene" wrote:> CBFalconer <cbfalconer@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++; } -- 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
Reply by ●August 10, 20072007-08-10
In news:f9d3og$1ng$2@engnntp2.cig.mot.com timestamped Wed, 8 Aug 2007 18:58:24 +0000 (UTC), ziomek@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"?
