MISRA owes a lot to Les Hatton's work as described in "Safer C". Les Hatton is *very* bright. But Les's vision got diluted more and more (particularly in the first version of MISRA) by people who perhaps didn't know the language anything like as well as he did.
pete
--
pete@fenelon.com "how many clever men have called the sun a fool?"
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.
I notice that the link you provided was from 2005.
--
********************************************************************
Paul E. Bennett ....................
Yes, there is a lot of silly things like that in MISRA. It is quite difficult to be 100% compliant.
Yes, this is correct. First of all, an integer should not be used as the switch argument; switches should be used with enums only.
Yes, this is correct. You should not modify, alias or copy the pointers. Work with arrays and indexes only.
So? Should we file the complaint to the UN?
It is better then nothing, anyway.
I had to write MISRA compliant code, and yes, it is too restrictive and very annoying at times. Nevertheless it does a good job on extirpating the hackery.
Without signifficant changes and
MISRA is not too bad. You just have to get used to it.
Unfortunately, there is no replacement for the common sense, experience, good taste and intelligence (Stroustrup).
If you are paid to write MISRA compliant code, you should write MISRA compliant code. What is the problem?
On 26 Mar 2007 14:45:23 -0700, snipped-for-privacy@rootshell.be wrote in comp.arch.embedded:
...and even more so, PC Lint. With a modified version of its MISRA rule set, to skip the more obnoxious MISRA rules.
"Shame on MISRA" is far too strong a statement.
There are some MISRA rules that I consider useless. On the other hand, there is a lot of good there. It is certainly better, as a whole, than anything else I have ever seen, especially for safety critical embedded systems.
And the 2004 version has some improvements, although I have never specifically tried to analyze all of the differences between the two.
I view the MISRA standard like I view the C standard. Both are efforts by a committee of people, and both have done a remarkably good job overall, but neither is perfect. Nothing generated by human beings is.
I have seen a fair number of articles criticizing the shortcomings of MISRA C, but I have yet to see any of the critics offering an improved alternative.
Perhaps it is just because I am the one who sets the embedded C coding guidelines for my organization, so I get to decide which of the MISRA rules we embrace and which we ignore.
Note to Chris Hills: I am not now, and never have, hidden behind a fake email address on usenet.
We don't know what u8 is, but nevertheless, u8Ptr1 is a pointer to a u8 and u8Ptr2 is a u8. The warning "performing pointer arithmetic" doesn't seem to apply. In a non-MISRA context, I would have expected to see a warning about type incompatibility.
We don't know what u8 is, but nevertheless, u8Ptr1 is a pointer to a u8 and u8Ptr2 is a u8. The warning "performing pointer arithmetic" doesn't seem to apply. In a non-MISRA context, I would have expected to see a warning about type incompatibility.
The other people involved in the background were also quite clever. Three of them came from one place.... The author of the link the OP cited was one of the three.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
Thanks. It is not perfect but we hope better than most other options.
I note that the JSF++ was based on MISRA-C
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
Others have tried but it takes a LOT of work.
The MISRA team meet for 2 full days every 12 weeks and do other MISRA work in between. Between us we have access to something like 10 major C code analysis tools for testing the rules as well as many decades of experience of real work problems and projects. Mostly in high integrity and safety critical systems.
The review team is a couple of hundred strong and includes SAE, JSAE, JAMA, HIS etc
That is fine They are there for guidance. I have always said "You can deviate all you want as long as you can stand by your deviations a few years down the line in a court of law ." That usually makes people think... which is the best we can hope for.
Never said you were I was addressing the comment to snipped-for-privacy@rootshell.be
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
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];
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.
In the end, the programmer must not just follow the rules, but also understand the reasoning behind them, and must apply the same philosophy to the rest of his work. It should not come as a surprise that a set of guidelines can be subverted by a sufficiently motivated person.
MISRA comes with clear and straightforward guideline documentation. This documentation explains the reasoning behind every rule, and suggests the whole methodology of the development. Most of the MISRA philosophy is just the common sense and good software development practice.
In this case, MISRA acts as the disciplinary tool forcing the stubborn donkeys to comply to the letter of the rules at the least.
...But the point of MISRA and such is not to be proof against the bad guys, but to rein in the prima donnas and "clever" programmers who think it's cool to write obscure code that does strange things just because they think they can, and the even worse fools who "don't want their creativity limited".
(that's a particular thorn in my side right now, having to modify code from one these idiots).
Indeed, Derek's company does some excellent work and Derek writes some very trenchant and elegant papers.
I was referring more to some of the end-user companies involved in MISRA; I've dealt with some of the automotive companies involved and been less than 100% impressed with their grasp of the subtleties.
pete
--
pete@fenelon.com "how many clever men have called the sun a fool?"
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.