Reason behind MISRA rule 111

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:

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