Hi Vikas, On 5/12/2011 4:00 AM, vikasvds wrote:> I am just curious to know what the reason behind MISRA rule 111.Why do you *care* what MISRA has to say? Considering "rules" to be anything other than "guidelines" abrogates your design responsibilities to some dweeb who *thinks* he can foresee everything that you *might* do "wrong" and opt to protect you from yourself. *At* some expense (reliability, cost, maintainability, etc.) Most *guidelines* point out issues that a conscientious designer should already be aware of -- undefined behaviors in The Standard, compiler-specific variations, etc. Avoiding something *simply* because a piece of paper says "you might get screwed" is intended for The Mindless Masses who don't/can't think things through. ("Don't run with scissors" -- "But, if I *walk*, the patient will be *dead* before I get there!") It's simplistic to think that imposing a simple set of "rules" (so simple, in fact, that the compiler can check and enforce them!) is going to make a dramatic difference. "Yes, I dotted all my i's and crossed all my t's... but I still don't know the difference between a noun and a verb..." Figure out what your client/user/industry requires and *try* to adhere to that. But, most of all, *understand* why your client wants to impose those constraints and make sure that your *client* understands the consequences of those constraints. E.g., writing code for a *gaming* system to MISRA is one sure way to get yourself laughed out of the regulatory process! (I suspect DoD would simply smile at you and tell you to go back and "do it over"...) *If* your client insists on MISRA compliance, write your code to suppress all of those warnings, shrug your shoulders and cash their check letting them *think* they "bought something (MISRA compliance) worthwhile". [this is often the path of least resistance rather than trying to educate them to the folly behind this -- "write in ADA and software quality will improve"...] Good luck!
Reason behind MISRA rule 111
Started by ●May 12, 2011
Reply by ●May 14, 20112011-05-14
Reply by ●May 14, 20112011-05-14
Arlet Ottens wrote:> On 05/13/2011 10:28 PM, Vinzent Hoefler wrote: > >>> If you use the bitfields only internally, there are no portability >>> concerns. >> >> LOL. >> >> It would be nice to use bitfields to define device register and that >> simply ain't possible in a "portable" (e.g. compiler-independent) way, >> because the representation may change once a different compiler has been >> chosen by the customer. BTSTFU. > > I meant internally, only as a method to cram more data in the same > memory. Using bitfields in device interfaces, is no longer 'internal'.Sure. And if you do that, you do not rely on a specific internal representation and all is well.> Still, you could define device registers using bitfields, if you include > some #ifdef COMPILER_XYZ around it, followed by > > #else > #error Please add register definitions for this compiler > #endifWhich certainly violates MISRA rule 10 then: "Sections of code should not be 'commented out'." ;)> Which exposes portability problems. Switching compilers mid-project is > pretty rare anyway, and very few embedded projects are 100% portable > between compilers. Try implementing a portable interrupt handler, for > instance.The interrupt handler was no problem for the self-written emulator. But that the two different compilers decided to count the bits from different directions, was. Vinzent. -- A C program is like a fast dance on a newly waxed dance floor by people carrying razors. -- Waldi Ravens
Reply by ●May 14, 20112011-05-14
On 05/14/2011 10:25 AM, Vinzent Hoefler wrote:>> Still, you could define device registers using bitfields, if you include >> some #ifdef COMPILER_XYZ around it, followed by >> >> #else >> #error Please add register definitions for this compiler >> #endif > > Which certainly violates MISRA rule 10 then: "Sections of code should > not be > 'commented out'." ;)In that case, just use different header files, and some Makefile tricks :)
Reply by ●May 15, 20112011-05-15
In message <iql7n4$vcv$1@speranza.aioe.org>, D Yuniskis <not.going.to.be@seen.com> writes>Hi Vikas, > >On 5/12/2011 4:00 AM, vikasvds wrote: >> I am just curious to know what the reason behind MISRA rule 111.>Figure out what your client/user/industry requires and *try* to >adhere to that.Many want MISRA compliance.>*If* your client insists on MISRA compliance, write your code to >suppress all of those warnings, shrug your shoulders and cash their >check letting them *think* they "bought something (MISRA compliance) >worthwhile".Sounds completely unethical and unprofessional to me. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●May 15, 20112011-05-15
Hi Chris, On 5/15/2011 3:01 AM, Chris H wrote:> In message<iql7n4$vcv$1@speranza.aioe.org>, D Yuniskis > <not.going.to.be@seen.com> writes >> >> On 5/12/2011 4:00 AM, vikasvds wrote: >>> I am just curious to know what the reason behind MISRA rule 111. > >> Figure out what your client/user/industry requires and *try* to >> adhere to that. > > Many want MISRA compliance.There are groups/individuals in every industry that aspire to create/impose "standards" on the work performed *in*/for that industry. Most appear to be motivated by "noble causes". They all suffer from trivializing what is a complex problem. I've seen movements to make engineers legally *liable* for the consequences of their designs ("Sure! And when do I get veto power over MY BOSS??"). I've seen folks insist that only "qualified" individuals write the code ("So, does this require a certain type of education? A certain level of intelligence?"). When the first MISRA release came out, a client waved it under my nose AS IF this would make the code I was about to write for him better -- *magically*. In the time it took me to skim the document (over lunch), I was able to show him that: - much of it falls under the category of "don't use undefined or implementation-defined behaviors" - some things were inconsistent ("test error values returned by functions" -- but *don't* use errno??) - some things were crippling ("break" and "continue" -phobia!) - some of it was just *silly* (the dreaded '$' character and the *sinister* "register" qualifier -- not to mention the worrisome *comma* operator!) Much of the code I wrote last week would complain because of my liberal use of offsetof()! :< Needless to say, he dropped the compliance requirement, I've heard of no deaths/injuries/recalls associated with the product. In fact, I've not had a single bug-fix request for it, either ("bug fixes" are "free" and immediate -- a *practical* way to keep pressure on the developer to provide quality code) [apologies if I have misremembered any of this and/or if changes have been made in the years since this event] *Personally*, I abhor "closed" and "for pay" standards -- if what you have is so wonderful (and really little more than a piece of electronic paper), why horde it?>> *If* your client insists on MISRA compliance, write your code to >> suppress all of those warnings, shrug your shoulders and cash their >> check letting them *think* they "bought something (MISRA compliance) >> worthwhile". > > Sounds completely unethical and unprofessional to me.How so? By giving the client what he claims to *want*? "Here, hire a team of (fill-in-the-blank) experts. Have them pour over the code for many man years. Let them convince you the code I've delivered is 100.00000000000% (fill-in-the-blank) compliant. Go to bed with peace of mind *hoping* that you really have a safe/secure/robust/'whatever' product/system (because that's what you *think* this compliance is giving you)" These sorts of "Rules" try to make "better coders" out of run-of-the-mill coders by artificially imposing constraints on *how* they do *what* they do. But, they just shift attention to "silencing compiler warnings" instead of rethinking what they might be "doing wrong". "Aw, crap! The compiler says I have two 'return' statements in this function. Now I have to rewrite the damn thing so there is only *one*... (regardless of how inappropriate that may be for this piece of code)" It's the "Just Say No" (to drugs) mentality -- as if a catchy saying will solve the problem. The hope/delusion that you can (effectively) *LEGISLATE* quality, etc. Spend your resources hiring and training better staff so they design *in* quality from the start. By far, the best environments I've found are those in which peer pressure (*not* "competition") inspires you to produce a quality product. Those in which "compliance" is pushed down "from above" end up fostering CYA behavior: "The code passed the compliance suite! It's not *my* fault..."
Reply by ●May 15, 20112011-05-15
D Yuniskis wrote:> Hi Chris, > > On 5/15/2011 3:01 AM, Chris H wrote: >> In message<iql7n4$vcv$1@speranza.aioe.org>, D Yuniskis >> <not.going.to.be@seen.com> writes >>> >>> On 5/12/2011 4:00 AM, vikasvds wrote: >>>> I am just curious to know what the reason behind MISRA rule 111. >> >>> Figure out what your client/user/industry requires and *try* to >>> adhere to that. >> >> Many want MISRA compliance. > > There are groups/individuals in every industry that aspire to > create/impose "standards" on the work performed *in*/for that > industry. Most appear to be motivated by "noble causes". > They all suffer from trivializing what is a complex problem.MISRA is not about making the code better. MISRA is about eliminating common sources of errors ("common" as in "statistically proven", which OTOH doesn't mean there aren't any other or that such requirements do not lead to other sources of errors ("others" as in "individually proven"). That said, I certainly doubt that obeying the rules of MISRA accomplished anything for someone who knows what s/hes doing. But that's also an individual perception, of course, not a statistically proven one. Vinzent. -- A C program is like a fast dance on a newly waxed dance floor by people carrying razors. -- Waldi Ravens
Reply by ●May 15, 20112011-05-15
Hi Vinzent, On 5/15/2011 8:10 AM, Vinzent Hoefler wrote: [snip]>>>>> I am just curious to know what the reason behind MISRA rule 111. >>> >>>> Figure out what your client/user/industry requires and *try* to >>>> adhere to that. >>> >>> Many want MISRA compliance. >> >> There are groups/individuals in every industry that aspire to >> create/impose "standards" on the work performed *in*/for that >> industry. Most appear to be motivated by "noble causes". >> They all suffer from trivializing what is a complex problem. > > MISRA is not about making the code better. MISRA is about eliminating > common sources of errors ("common" as in "statistically proven", which > OTOH doesn't mean there aren't any other or that such requirements do > not lead to other sources of errors ("others" as in "individually proven").Correct. But, anyone "skilled in the art" *should* already know most of the issues that MISRA tries to address (replace "MISRA" with damn near any other "standard"). I contend that adopting these sorts of "standards" and the imperatives they impose ends up focusing attention on trivialities -- attention that should, instead, be focused on *bigger* issues. 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. [this comes back to my assertion that "rules" should always be GUIDELINES. There's a big difference between a compiler offering reminders/suggestions -- "missing else", etc. -- to help catch problems. It's another thing entirely to require/prohibit certain things for fear they *might* cause problems.]> That said, I certainly doubt that obeying the rules of MISRA accomplished > anything for someone who knows what s/hes doing.But it (and similar "standards") can be counterproductive by forcing implementations to take "unnatural" forms. For example, I often wrap a section of code in a do-while(1) and liberally "break" out of that control structure (for error conditions, etc.). MISRA tells me this is "prohibited". So, I am now forced to contort the code to comply with this *arbitrary* prohibition just in case I might not be smart enough to use it properly? Should we *ban* division because folks forget to test the denominator for zero? Should we *ban* "==" because folks fail to implement fuzzy equality tests for floats? Should we *ban* the use of the value "10" because some might consider it 10r10 while others consider it 10r2, 10r8 or 10r16? (or, perhaps we should ban all non-decimal radix? or, force all constants to explicitly declare their radix *and* data type -- is 50,000 a long or an int?) Do you assume your staff are *competent* and provide them with tools to assist them in the performance of their duties? Or, do you assume they are INcompetent and impose a policeman/regulator to watch over them and scold them each time they do something "unexpected"?> But that's also an > individual perception, of course, not a statistically proven one.Spend your resources ($$) on improving the quality of your staff. That's something that will benefit you in other ways that things like artificial "standards" can *never* address. Over the years, I've found that "coding" is the *least* important of the aspects of product development. By far, proper *specification* and *testing* will result in a higher quality product (by *any* measure of "quality") than attempts to micromanage the "coding". (e.g., I budget 40% of my time for specification/design and 40% for testing/verification/validation... so "coding" takes a scant 20% of the effort. IMO, energy spent trying to improve that has far less impact on the result than improvements in this other "80%"). YMMV, of course.
Reply by ●May 15, 20112011-05-15
On 15/05/11 16:33, D Yuniskis wrote:> Hi Chris, > > On 5/15/2011 3:01 AM, Chris H wrote: >> In message<iql7n4$vcv$1@speranza.aioe.org>, D Yuniskis >> <not.going.to.be@seen.com> writes >>> >>> On 5/12/2011 4:00 AM, vikasvds wrote: >>>> I am just curious to know what the reason behind MISRA rule 111. >> >>> Figure out what your client/user/industry requires and *try* to >>> adhere to that. >> >> Many want MISRA compliance. > > There are groups/individuals in every industry that aspire to > create/impose "standards" on the work performed *in*/for that > industry. Most appear to be motivated by "noble causes". > They all suffer from trivializing what is a complex problem.Not /all/ suffer from trivializing complex problems. Just as many suffer equally from complicating trivial problems.> > *Personally*, I abhor "closed" and "for pay" standards -- if what > you have is so wonderful (and really little more than a piece of > electronic paper), why horde it? >As far as I am concerned, a set of rules or definitions is not a standard unless it is well-maintained by a reputable body, freely available to view by anyone who wants it, freely implementable by anyone who wants to, represents a real and practical document that is widely followed, and adapts as required by its users, and modern developments. Without that, it's just a set of private rules for a particular club. That's fine in itself - private rules have lots of uses. But it is not a standard. I have an even lower opinion of those who call their club rules "open standards" and yet still charge vast amounts to sell you a pseudo-pdf file that you can't use properly. I understand that it costs a lot of money to produce such a set of rules, and that not everything can be state-sponsored even if it is for the greater good. But there are plenty of ways to make money from such an endeavour - charge for certification or the use of logos, sell printed books, provide courses and training, consultancy fees, compliance-checking software, etc.> By far, the best environments I've found are those in which peer > pressure (*not* "competition") inspires you to produce a quality > product. Those in which "compliance" is pushed down "from above" > end up fostering CYA behavior: "The code passed the compliance > suite! It's not *my* fault..."You'll hear that a lot, regarding the code itself, the methodology used to write it, and the development tools to compile it. Some people think it is more important for a compiler to have passed a particular certification suite than to be correct - because then you can use that certification as a defence in court if you get sued.
Reply by ●May 15, 20112011-05-15
Hi David, On 5/15/2011 9:23 AM, David Brown wrote:>> There are groups/individuals in every industry that aspire to >> create/impose "standards" on the work performed *in*/for that >> industry. Most appear to be motivated by "noble causes". >> They all suffer from trivializing what is a complex problem. > > Not /all/ suffer from trivializing complex problems. Just as many suffer > equally from complicating trivial problems.The same can be said of the language gods trying to design the capacity for "error" (?) out of a language. Eventually, you end up with a language that isn't useful for anything other than academia :> Educate; don't Legislate (impose).>> *Personally*, I abhor "closed" and "for pay" standards -- if what >> you have is so wonderful (and really little more than a piece of >> electronic paper), why horde it? > > As far as I am concerned, a set of rules or definitions is not a > standard unless it is well-maintained by a reputable body, freely > available to view by anyone who wants it, freely implementable by anyone > who wants to, represents a real and practical document that is widely > followed, and adapts as required by its users, and modern developments.+42> Without that, it's just a set of private rules for a particular club. > That's fine in itself - private rules have lots of uses. But it is not a > standard. > > I have an even lower opinion of those who call their club rules "open > standards" and yet still charge vast amounts to sell you a pseudo-pdf > file that you can't use properly. > > I understand that it costs a lot of money to produce such a set of > rules, and that not everything can be state-sponsored even if it is for > the greater good. But there are plenty of ways to make money from such > an endeavour - charge for certification or the use of logos, sell > printed books, provide courses and training, consultancy fees, > compliance-checking software, etc.Or, hope for the benevolence of "key players" in those industries to underwrite all or part of their efforts. Things like Standards are so tenuous that you have to be wary that The Industry might just pick up and head off in a different direction regardless of your concern/interests. The problem with "paid" organizations promoting/sponsoring things like this is they tend to be self-perpetuating. They have a vested interest in "their" Standard. So, the biological organisms involved in it have a *huge* stake -- their SALARIES!>> By far, the best environments I've found are those in which peer >> pressure (*not* "competition") inspires you to produce a quality >> product. Those in which "compliance" is pushed down "from above" >> end up fostering CYA behavior: "The code passed the compliance >> suite! It's not *my* fault..." > > You'll hear that a lot, regarding the code itself, the methodology used > to write it, and the development tools to compile it. Some people think > it is more important for a compiler to have passed a particular > certification suite than to be correct - because then you can use that > certification as a defence in court if you get sued.By comparison, if you inspire people to take *personal* ownership of their product, they actually *care* about what they are producing and *want* it to work/be better, etc. Abrogating some/any portion of your "ownership" of a product leaves you exposed to whatever "deficiencies" that other organization brings to the table (i.e., what if their quality isn;t up to par? what if they have made a mistake? etc.). You can never protect completely against litigation (or stupidity!). So, you do some *reasonable* amount of "due diligence" and hope for the best. It's folly to try to design a hammer that *can't* be used to hit your own foot... or a wood chisel that can't be used to cut aluminum gutters. OTOH, it costs very little to provide written warnings against these sorts of things...
Reply by ●May 16, 20112011-05-16
D Yuniskis wrote:> > MISRA is not about making the code better. MISRA is about eliminating > > common sources of errors ("common" as in "statistically proven", which > > OTOH doesn't mean there aren't any other or that such requirements do > > not lead to other sources of errors ("others" as in "individually proven"). > > Correct. But, anyone "skilled in the art" *should* already > know most of the issues that MISRA tries to address (replace > "MISRA" with damn near any other "standard"). > > I contend that adopting these sorts of "standards" and the > imperatives they impose ends up focusing attention on > trivialities -- attention that should, instead, be focused > on *bigger* issues. > > 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. 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. Regards, -- Walter Banks Byte Craft Limited http://www.bytecraft.com