EmbeddedRelated.com
Forums
Memfault State of IoT Report

Reason behind MISRA rule 111

Started by vikasvds May 12, 2011
Hi Walter,

On 5/16/2011 7:33 AM, Walter Banks wrote:
>>>> It's the same sort of mentality that seeks to impose "style >>>> guidelines" on code in an attempt to make it more readable, >>>> maintainable, etc. People end up working to appease the >>>> Standard's God instead of focusing on the product they are >>>> preparing. >>> >>> Coding standards misra and others do a lot to make big projects >>> much more reliable. They tend to force people to use clear >>> statements devoid of the kind of one of programming tricks >>> that create debugging and application nightmares. >> >> Coding *guidelines* can have the same effect -- without the >> "policeman". If your staff aren't competent enough to >> understand the costs and benefits associated with different >> language features, then you have bigger problems than a >> "standard" can fix. >> >>> I have seen a lot of code written by many different people >>> the best fastest and most easy to maintain code is simple >>> and clear and let modern tools do there work. >>> >>> misra is a low cost standard well worth the cost. >> >> The "cost" of an e-file isn't the issue. Rather, the cost >> of BLINDLY (i.e., following the "shalls" and "shoulds") >> adhering to it can be significant! >> >> Standards cost a lot more than the "paper" they're written >> on. Someone has to codify an enforcement policy for your >> organization, put in place mechanisms to verify compliance, >> maintain any tools that are required for these activities, >> educate users as to why rules that obviously have significant >> coding consequences are BLINDLY enforced ("Yes, we value you >> as an employee... we just don't think you are smart enough >> to know when *to* use a goto/break/continue/etc. and when >> *not* to -- so we'll just make it illegal to use them!"), >> determine (in some empirical manner) if the costs are being >> justified by productivity increases, etc. >> >> Or, go the DoD route -- impose heavy-handed "requirements" >> on the code, the coding *process*, specification, testing, >> etc. *That* sure seems to have worked out well for *them*, >> eh? ;-) > > Coding standards are a lot like author standards from a > publishing house. They are a way to create a consistent > implementation. BTW the DoD route does work. Some > of the best development groups that I know have serious > standards in place that they follow. > > The 20% coding costs that you quoted elsewhere is > about double the cost of coding and debug of many
That's *my* cost. How many projects outside of big shops do you know that can meet that goal? How many of these have you seen specifications, test suites, etc.? Big projects, big shops impose lots of overhead. They justify it because of the size of the project, the fact that they need a large team, that there will be *big* variations in the skillsets of team members, that some significant portion of those team members may "move on" before the project is completed, etc.
> big projects that I know. Good software is engineered
Exactly. -------------------------^^^^^^^^^^^^
> and not a black art and good engineering standards > and practices produces products that are lower cost > and more reliable.
And your contention is that GUIDELINES are NOT EFFECTIVE? That you can't *trust* your staff to "do the right thing" without *enforcement*? I try to design things (hardware, software, systems) so that it is easiest for those who follow me to "do the right thing". But, I don't *prevent* them from doing something *else* -- as I am not prescient. I trust them to know when to go in a different direction. Substitute "guidelines" for "standards" and I heartily agree with your last statement!

D Yuniskis wrote:

> On 5/16/2011 7:33 AM, Walter Banks wrote:
> > > The 20% coding costs that you quoted elsewhere is > > about double the cost of coding and debug of many big projects that I know. > > That's *my* cost. How many projects outside of big > shops do you know that can meet that goal? How many > of these have you seen specifications, test suites, etc.?
I write compilers for a living, I deal with customers ranging from one man job shops to very large companies.
> That you can't *trust* your staff to "do the right thing" > without *enforcement*?
Standards are not about trust or enforcement they are about disciplined engineering. w..
Walter Banks wrote:
> D Yuniskis wrote: >>It's the same sort of mentality that seeks to impose "style >>guidelines" on code in an attempt to make it more readable, >>maintainable, etc. People end up working to appease the >>Standard's God instead of focusing on the product they are >>preparing. > > Coding standards misra and others do a lot to make big projects > much more reliable. They tend to force people to use clear > statements devoid of the kind of one of programming tricks > that create debugging and application nightmares.
Do they? Sorry, my practice differs wildly. The only tools which have ever *found* real bugs in my code were cppcheck and PREfast. Both are free, I might add. And both found bugs because they know the APIs I use. Our MISRA checker mostly makes problems because it's hard to set up and does not parse perfectly valid code (such as 'char foo[] = { "foo" }', which is valid C [ISO 9899:1999 �6.7.8(14)]). To add irony, their website claims they understand the language standards better than most developers. Does MISRA improve code quality? People want measurable quality. Using MISRA the seemingly-usual way ("we want zero violations") is well measurable, but does not improve code quality. �2.4 "Sections of code shall not be commented out." This forbids me to write examples in my comments ("these three functions are used with a for() loop like this: ..."). The intent of the rule is to avoid (a) old code hanging around in comments (which is indeed very annoying), and (b) to have a screenful of code which is not compiled because I don't see the comment delimiters. But the intent is not measurable. The described workaround solves neither problem. And (b) could be very easily solved using "//" comments. Alas, they are forbidden. �7.1 "Octal constants [...] shall not be used." How does my code get any better if I have to specify file permissions in hex (or with lengthy constants)? Everyone knows what mode 0755 is. But do you know what S_IRWXO is (without looking up the octal value)? �10 requires casts for almost everything. How does my code get any better when I have to write 'a = (uint8_t) (b & 255)' instead of just 'a = (b & 255)'? The observable result is just that it gets slower. �14.1 says no unreachable code. �15.3 says I need a 'default' clause in switches, even if I have already covered all possibilities. How does this go together? And �14.1 forbids me that defensive 'return 0' after a thread's 'while(1)' main loop - which means some compilers now annoy me with a warning about a missing return, and the code breaks when someone changes the loop to stop. �20.5 "The error indicator errno shall not be used." How does my code get any better when I ignore errors from 'fopen'? MISRA is good when it encourages people to think before they type. I know MISRA doesn't want me to use macros. I also know that 90% of all compilers/optimizers explode on my codec when I use inline functions instead. So I can write you a nice paper for a deviation why I need macros here (and only here). But don't treat me like a lobotomized chimpanzee who cannot distinguish "||" and "|" operators. Stefan
Stefan Reuther wrote:

> MISRA is good when it encourages people to think before they type. > I know MISRA doesn't want me to use macros. I also know that 90% of all > compilers/optimizers explode on my codec when I use inline functions > instead. So I can write you a nice paper for a deviation why I need > macros here (and only here).
And that's all what's needed. You don't have to obey the rules if you can reason why they don't make sense in a particular case. That just documents you thought about it. Look at it this way: The rules are not for you (because you know what you're doing, of course), the rules are for the engineer maintaining the code after you (because he's the one who doesn't know what you were doing).
> But don't treat me like a lobotomized > chimpanzee who cannot distinguish "||" and "|" operators.
You don't need lobotomy for that. Quite often the standard biological neural network tends to see only what you expect it to see. Vinzent. -- A C program is like a fast dance on a newly waxed dance floor by people carrying razors. -- Waldi Ravens
Vinzent Hoefler wrote:
> Stefan Reuther wrote: >> MISRA is good when it encourages people to think before they type. >> I know MISRA doesn't want me to use macros. I also know that 90% of all >> compilers/optimizers explode on my codec when I use inline functions >> instead. So I can write you a nice paper for a deviation why I need >> macros here (and only here). > > And that's all what's needed. You don't have to obey the rules if you > can reason why they don't make sense in a particular case. That just > documents you thought about it.
I know that. Tell that the QA inquisition. Compare <http://www.leshatton.org/Documents/MISRA_comp_1105.pdf>, which concludes: | [...] this paper attempts to assess whether important deficiencies in | the original standard have been addressed satisfactorily. | Unfortunately, they have not and the important real to false positive | ratio is not much better in MISRA C 2004 than it was in MISRA C 1998 | and it is unacceptably low in both. [...] | | [MISRA C 2004] has not solved the most fundamental problem of MISRA C | 1998, viz. that its unadulterated use as a compliance document is | likely to lead to more faults and not less because of the fault | re-injection phenomenon first noted by [1]. Which precisely matches my observation. Still, people want "zero derivations, 100% compliance".
>> But don't treat me like a lobotomized >> chimpanzee who cannot distinguish "||" and "|" operators. > > You don't need lobotomy for that. Quite often the standard biological > neural network tends to see only what you expect it to see.
Actually, I haven't ever had a bug regarding to those two. (However, I already had a couple of functions where I added a comment "yes, I'm really using '|' on bools here because I want both paths", to reduce that "oops, shouldn't there be two of them" feeling.) Which is precisely my problem with most coding standards. They don't find or prevent *practical* bugs. Yes, they make code a little nicer and more consistent, which is why I'm at least following those parts. But when I have to rewrite well-tested and perfectly working code just to get it through the checker, the coding standard has failed its goal. Stefan
Hi Walter,

On 5/16/2011 9:15 AM, Walter Banks wrote:
>>> The 20% coding costs that you quoted elsewhere is >>> about double the cost of coding and debug of many big projects that I know. >> >> That's *my* cost. How many projects outside of big >> shops do you know that can meet that goal? How many >> of these have you seen specifications, test suites, etc.? > > I write compilers for a living, I deal with customers > ranging from one man job shops to very large > companies.
But you didn't answer either of the two questions I posed! What are the relative costs that you see in that *range* of "customers" and customer projects? I'm *sure* the "coding costs" for SDI, e.g., are a tiny fraction of the total project costs, etc. Does that mean they write better code? More *efficient* coders? *Or*, that as a percentage of an incredibly large project, the costs are RELATIVELY smaller??
>> That you can't *trust* your staff to "do the right thing" >> without *enforcement*? > > Standards are not about trust or enforcement they > are about disciplined engineering.
As are *guidelines*! The difference is *solely* "trust and enforcement"! (what is a Standard *without* the LACK of trust and IMPOSED enforcement? Don't you call that a *guideline*?! "Advice"? "Best practices"?)
Hi Stefan,

On 5/16/2011 10:05 AM, Stefan Reuther wrote:

> &#4294967295;7.1 "Octal constants [...] shall not be used." How does my code get any > better if I have to specify file permissions in hex (or with lengthy > constants)? Everyone knows what mode 0755 is. But do you know what > S_IRWXO is (without looking up the octal value)?
Actually, I really *hate* the way octal is indicated in C. I much prefer the <value>r<radix> notation. It is extensible (to other radix), unambiguous, doesn't add much clutter to the code and doesn't "magically" assign extra value to things like leading zeroes. (I got bit by #include-ing some tables of constants that were created with leading zero padding instead of leading spaces)
> &#4294967295;20.5 "The error indicator errno shall not be used." How does my code > get any better when I ignore errors from 'fopen'?
Isn't there *also* a requirement that "error values" from functions be explicitly tested (e.g., malloc returning NULL)? So, test it everywhere *except* those cases where a mechanism has explicitly been created for this purpose. (how do you code for range errors on something like pow(a,b) if you can't look at errno? do you try to detect the error in the *domain*, instead? *try* it! :> )
> MISRA is good when it encourages people to think before they type.
But that is true of *any* "guideline". Where things go awry is when some *thing* (a "Standard") unilaterally tries to *force* (and ENforce) a behavior/practice without knowledge of the application, individual, etc. Tools should *enable* good practices by assisting the user, not try to *force* practices that *hope* to make things better.
> I know MISRA doesn't want me to use macros. I also know that 90% of all > compilers/optimizers explode on my codec when I use inline functions > instead. So I can write you a nice paper for a deviation why I need > macros here (and only here). But don't treat me like a lobotomized > chimpanzee who cannot distinguish "||" and "|" operators.
+42
On Mon, 16 May 2011 23:04:37 +0200, Stefan Reuther
<stefan.news@arcor.de> wrote:

>>> But don't treat me like a lobotomized >>> chimpanzee who cannot distinguish "||" and "|" operators. >> >> You don't need lobotomy for that. Quite often the standard biological >> neural network tends to see only what you expect it to see. > >Actually, I haven't ever had a bug regarding to those two. (However, I >already had a couple of functions where I added a comment "yes, I'm >really using '|' on bools here because I want both paths", to reduce >that "oops, shouldn't there be two of them" feeling.)
Here I think C overdid it. As I like readable code - especially if I am the one to read it some years into the future I use several #define. e.g. | BITOR || OR ... The | can be overseen very easily if the formulas are written without enough parenteses and spaces. RK
In message <4dd26c5d.698571843@news.inode.at>, Reinhard Kopka
<kopka@gmx.de> writes
>On Mon, 16 May 2011 23:04:37 +0200, Stefan Reuther ><stefan.news@arcor.de> wrote: > >>>> But don't treat me like a lobotomized >>>> chimpanzee who cannot distinguish "||" and "|" operators. >>> >>> You don't need lobotomy for that. Quite often the standard biological >>> neural network tends to see only what you expect it to see. >> >>Actually, I haven't ever had a bug regarding to those two. (However, I >>already had a couple of functions where I added a comment "yes, I'm >>really using '|' on bools here because I want both paths", to reduce >>that "oops, shouldn't there be two of them" feeling.) > >Here I think C overdid it. As I like readable code - especially if I >am the one to read it some years into the future I use several >#define. > >e.g. >| BITOR >|| OR >... > >The | can be overseen very easily if the formulas are written without >enough parenteses and spaces.
I give you rule 36 from MIStRAy-C Rule 36 Remember that and is and and or is or. The compiler can usually tell by context the difference between && & & & II & I & ~ &! -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reinhard Kopka wrote:
> On Mon, 16 May 2011 23:04:37 +0200, Stefan Reuther >>Actually, I haven't ever had a bug regarding to those two. (However, I >>already had a couple of functions where I added a comment "yes, I'm >>really using '|' on bools here because I want both paths", to reduce >>that "oops, shouldn't there be two of them" feeling.) > > Here I think C overdid it. As I like readable code - especially if I > am the one to read it some years into the future I use several > #define. > > e.g. > | BITOR > || OR > ... > > The | can be overseen very easily if the formulas are written without > enough parenteses and spaces.
Well, then add spaces when writing? I expect every C programmer to know that "||" means. But those macros break everyone's (mental and programmatical) parsers. And every second yacc parser which uses OR as the macro for a "||" token. If you insist on words, at least use <iso646.h>. It still breaks parsers, but at least it's standardized (and the names it defines are keywords in C++, making name clashes less likely). Stefan

Memfault State of IoT Report