Reason behind MISRA rule 111

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!

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
> #endif

Which 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

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 :)

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     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

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..."

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

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.

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.

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...

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