EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

shame on MISRA

Started by Unknown March 26, 2007
Chris Hills wrote: 
> Paul E. Bennett <peb@amleth.demon.co.uk> writes >> Chris Hills wrote: >> >>> You might think that I could not possibly comment >>> >>> See http://www.phaedsys.demon.co.uk/chris/mistrayc/MISTRAYC.pdf >>> for a REAL programmers guide for people who do not want their >>> creativity limited. > >> Except that the file could not be opened (even from the web page >> above it). > > Very strange as I cut and pasted the link from the web browser.... > Can any one else see the pdf OK?
No problem here. -- 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
On Tue, 27 Mar 2007 09:38:01 +0100, Chris Hills <chris@phaedsys.org>
wrote in comp.arch.embedded:

   [snip]

> There will be a TC and example suite soon and a MISRA-C V3 in a few > years. Hopefully it will have the same level of improvements between 2 & > 3 as 1 & 2
[snip] Chris, please be sure to post here when these things are available. Like most people, I do not visit the MISRA web site very often because, let's face it, it does not change very often. Also, if you are looking for outside reviewers and/or beta users of the TC or new version, I am willing to participate. Just email me at my completely undisguised address. I work, these days, in safety critical embedded control for medical devices, and we have incorporated a large part of MISRA C in our coding standards for several years now. I'll supply my company affiliation via email if you want it. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://c-faq.com/ comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
> The point of the OP was that you can trivially rewrite the offending > expression by the following, equally unsafe code, and avoid the > warning: > > u8Ptr1 = &u8Ptr2[N]; > > Or one could even avoid pointers altogether, and write something like > this, which can be as unsafe as the previous: > > N = /* complicated expression */ > a = u8Ptr2[N]; >
This can of course be made safer by a compiler if it is transformed to N = /* complicated expression */ ASSERT(N >= &u8Ptr2[0]); ASSERT(N < &u8Ptr2[MAX]); a = u8Ptr2[N]; Much harder to do with a pointer -- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
Op Tue, 27 Mar 2007 22:32:58 +0200 schreef <disident@rootshell.be>:
>> If your job requires that you write MISRA-compliant code, I would >> think you'd learn how to avoid the warnings and stop wasting precious >> time. > I agree but it is annoying all the time.
Anything that limits creativity is annoying. Everything that allows creativity is limiting.
> And the official position of > my employer is not clean. > And also clients of my employer think that _every_ MISRA deviation is > dangerous and terrible. And what I claim is that MISRA people are > guilty about this situation.
MISRA would be dead today if it didn't help developers to be careful about what they write and to solve mistakes at an early stage. Especially if missing a deadline means endangering the jobs of hundreds of people. Sure, it is possible to be careful and not be MISRA-compliant, but should your boss trust _all_ his developers to be careful enough _all_ the time? -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/
In news:eu9gbn$pt4$1$830fa7a5@news.demon.co.uk timestamped Mon, 26 Mar
2007 23:14:28 +0100, "Paul E. Bennett" <peb@amleth.demon.co.uk>
posted a response to an excellent example of classic MISRA C being
awful:
"I hope you are referring to the latest examples/code snippets released
(earlier this year I think) and not the snippets that came out with the
earlier version of the MISRA guidelines. Engineers should all be working to
current best practice and that means mindful of the latest and emergent
standards.

[..]"


MISRA does not do so. From WWW.MISRA-C2.com/faqs.htm :

"[..]

   Is C99 covered?

   MISRA-C:2004 is based on the C language as defined by ISO 9899:1990
   (plus
   corrigenda). C99 has not been considered in MISRA-C:2004 due to the
   limited
   support for C99 on embedded microprocessors.

[..]"
In news:euc4f5$gqd$2$8302bc10@news.demon.co.uk timestamped Tue, 27 Mar
2007 23:09:58 +0100, "Paul E. Bennett" <peb@amleth.demon.co.uk>
posted:
"Chris Hills wrote:

> They are freely available.
Unless he was another cheapskate looking for the zero cost version.
>>and I have >>not access to latest rules > > http://www.misra-c.com/
...and quite reasonable prices too." The Ada standard is available for gratis.
In news:9maOh.94188$ia7.33871@newsfe14.lga timestamped Tue, 27 Mar
2007 11:03:09 -0400, John Perry <jp@no.spam> posted:
"Arlet wrote:
> ... > > The bigger issue is that basically *any* random C program can be > converted into an equivalent program that complies with MISRA rules > (or any other set of similar rules, for that matter). This conversion > process can even be done fully automatically by a suitable tool. Of > course, simply rewriting code into a different syntactic form does > not, by itself, increase the safety. >"
I had been unaware of this. How? Does this apply to all such sets of rules? "...and the fault with MISRA is...? [..]" If it does not prohibit the practices it is supposed to, then that is a problem.
In news:xRZG4jK1JECGFAlo@phaedsys.demon.co.uk timestamped Mon, 26 Mar
2007 23:00:21 +0100, Chris Hills <chris@phaedsys.org> posted:
"In article <1174945523.344855.183480@n76g2000hsh.googlegroups.com>,
disident@rootshell.be writes
[..]

>please, for those who do not code using strict misra checker: do not >argue that MISRA is good. Without signifficant changes and >improvements to these rules, it is not more than annoying tool. >Compiler warnings of a good CC are far more useful to prevent bugs at >early stage development.
And who are you to say this? You hide behind a fake email address. Identify yourself, make the comments again ." One does not need to identify one's self to make a comment. Do you deny that the warning messages which were alleged are invalid? People are unimportant. Truth is important.
In article <eue2jl$kvi$4@newsserver.cilea.it>, Colin Paul Gloster 
<Colin_Paul_Gloster@ACM.org> writes
>In news:xRZG4jK1JECGFAlo@phaedsys.demon.co.uk timestamped Mon, 26 Mar >2007 23:00:21 +0100, Chris Hills <chris@phaedsys.org> posted: >"In article <1174945523.344855.183480@n76g2000hsh.googlegroups.com>, >disident@rootshell.be writes >[..] > >>please, for those who do not code using strict misra checker: do not >>argue that MISRA is good. Without signifficant changes and >>improvements to these rules, it is not more than annoying tool. >>Compiler warnings of a good CC are far more useful to prevent bugs at >>early stage development. > > >And who are you to say this?
I should have thought that was self evident.
>You hide behind a fake email address. >Identify yourself, make the comments again ." > >One does not need to identify one's self to make a comment. Do you >deny that the warning messages which were alleged are invalid? People >are unimportant. Truth is important.
However disident@rootshell.be made anonymous allegations against the MISRA team. I just asked him to identify them and repeat them. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In article <eue0um$kvi$1@newsserver.cilea.it>, Colin Paul Gloster 
<Colin_Paul_Gloster@ACM.org> writes
>In news:eu9gbn$pt4$1$830fa7a5@news.demon.co.uk timestamped Mon, 26 Mar >2007 23:14:28 +0100, "Paul E. Bennett" <peb@amleth.demon.co.uk> >posted a response to an excellent example of classic MISRA C being >awful: >"I hope you are referring to the latest examples/code snippets released >(earlier this year I think) and not the snippets that came out with the >earlier version of the MISRA guidelines. Engineers should all be working to >current best practice and that means mindful of the latest and emergent >standards. > >[..]" > > >MISRA does not do so. From WWW.MISRA-C2.com/faqs.htm : > >"[..] > > Is C99 covered? > > MISRA-C:2004 is based on the C language as defined by ISO 9899:1990 > (plus > corrigenda). C99 has not been considered in MISRA-C:2004 due to the > limited > support for C99 on embedded microprocessors. > >[..]"
As has been said you need to read and understand not quote the letter... :-) -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

The 2024 Embedded Online Conference