shame on MISRA

Started by March 26, 2007
sample1.c (catch 22):
// Misra warning: file scope static, used in one function
static u8 X;

static f(void)
{
// Misra warning: it is not correct to use block scope static
variable. define it at file scope
     static u8 Y;
     X = ++Y;
}

sample2 (another catch 22):
void f(void)
{
    u8 X;
    .... performing some calculations, that guarantee X<2
    switch(X)
    {
         case 0: doSomething(); break;
         case 1: SomethingElse(); break;
  // choose between the following warning:
//   1. inaccessible default statement
//   2. case without default statement
         default: assert(0); break;
    }
}

sample3 (senseless code damage due to MISRA):
u8 *u8Ptr1,u8Ptr2;
u32 N;
.... some calculations

// Misra warning: performing pointer arithmetic
u8Ptr1 = u8Ptr2+N;

// The following replacement help us to decrease warning number
// No warning here! but this is semantically the same as above
according ISO & ANSI.
// It is exactly as (un)safe as the example above and generates the
same binary code:
u8Ptr1 = &u8Ptr2[N];

and many other examples - I don't remember them all.

finally, this is an excellent resume on MISRA stupidity:
http://www.knosof.co.uk/misracom.html

It is a set of rules, defined by not very clever people (especially
the older MISRA version) and used
by automotive software producers, because it looks nice for the
bureaucratic high-level managment.

please, for those who do not code using strict misra checker: do not
argue that MISRA is good. Without signifficant changes and
improvements to these rules, it is not more than annoying tool.
Compiler warnings of a good CC are far more useful to prevent bugs at
early stage development.

And do not wonder if you see buggy embedded software! A precious time
is spent every day to justify lots of senseless warnings.

In article <1174945523.344855.183480@n76g2000hsh.googlegroups.com>, 
disident@rootshell.be writes
> >finally, this is an excellent resume on MISRA stupidity: >http://www.knosof.co.uk/misracom.html > >It is a set of rules, defined by not very clever people (especially
The author of the link you cite was also involved in the first version of MISRA-C and is taking part in MISRA-C++
>please, for those who do not code using strict misra checker: do not >argue that MISRA is good. Without signifficant changes and >improvements to these rules, it is not more than annoying tool. >Compiler warnings of a good CC are far more useful to prevent bugs at >early stage development.
And who are you to say this? You hide behind a fake email address. Identify yourself, make the comments again . -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
disident@rootshell.be wrote:
> > It is a set of rules, defined by not very clever people (especially > the older MISRA version) and used
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?"
disident@rootshell.be wrote:

> finally, this is an excellent resume on MISRA stupidity: > http://www.knosof.co.uk/misracom.html > > It is a set of rules, defined by not very clever people (especially > the older MISRA version) and used > by automotive software producers, because it looks nice for the > bureaucratic high-level managment. > > please, for those who do not code using strict misra checker: do not > argue that MISRA is good. Without signifficant changes and > improvements to these rules, it is not more than annoying tool. > Compiler warnings of a good CC are far more useful to prevent bugs at > early stage development. > > And do not wonder if you see buggy embedded software! A precious time > is spent every day to justify lots of senseless warnings.
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 ....................<email://peb@amleth.demon.co.uk> Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/> Mob: +44 (0)7811-639972 Tel: +44 (0)1235-811095 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************

disident@rootshell.be wrote:

What MISRA checker are you using?


> sample1.c (catch 22): > // Misra warning: file scope static, used in one function > static u8 X; > > static f(void) > { > // Misra warning: it is not correct to use block scope static > variable. define it at file scope > static u8 Y; > X = ++Y; > }
Yes, there is a lot of silly things like that in MISRA. It is quite difficult to be 100% compliant.
> sample2 (another catch 22): > void f(void) > { > u8 X; > .... performing some calculations, that guarantee X<2 > switch(X) > { > case 0: doSomething(); break; > case 1: SomethingElse(); break; > // choose between the following warning: > // 1. inaccessible default statement > // 2. case without default statement > default: assert(0); break; > } > }
Yes, this is correct. First of all, an integer should not be used as the switch argument; switches should be used with enums only.
> sample3 (senseless code damage due to MISRA): > u8 *u8Ptr1,u8Ptr2; > u32 N; > .... some calculations > > // Misra warning: performing pointer arithmetic > u8Ptr1 = u8Ptr2+N;
Yes, this is correct. You should not modify, alias or copy the pointers. Work with arrays and indexes only.
> // The following replacement help us to decrease warning number > // No warning here! but this is semantically the same as above > according ISO & ANSI. > // It is exactly as (un)safe as the example above and generates the > same binary code: > u8Ptr1 = &u8Ptr2[N];
> and many other examples - I don't remember them all. > > finally, this is an excellent resume on MISRA stupidity: > http://www.knosof.co.uk/misracom.html
So? Should we file the complaint to the UN?
> It is a set of rules, defined by not very clever people (especially > the older MISRA version) and used > by automotive software producers, because it looks nice for the > bureaucratic high-level managment.
It is better then nothing, anyway.
> please, for those who do not code using strict misra checker: do not > argue that MISRA is good.
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
> improvements to these rules, it is not more than annoying tool.
> Compiler warnings of a good CC are far more useful to prevent bugs at > early stage development. MISRA is not too bad. You just have to get used to it.
> And do not wonder if you see buggy embedded software!
Unfortunately, there is no replacement for the common sense, experience, good taste and intelligence (Stroustrup).
> A precious time > is spent every day to justify lots of senseless warnings.
If you are paid to write MISRA compliant code, you should write MISRA compliant code. What is the problem? Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
On 26 Mar 2007 14:45:23 -0700, disident@rootshell.be wrote:

>And do not wonder if you see buggy embedded software! A precious time >is spent every day to justify lots of senseless warnings.
If your job requires that you write MISRA-compliant code, I would think you'd learn how to avoid the warnings and stop wasting precious time. -- Al Balmer Sun City, AZ
On 26 Mar 2007 14:45:23 -0700, disident@rootshell.be wrote in
comp.arch.embedded:

> sample1.c (catch 22): > // Misra warning: file scope static, used in one function > static u8 X; > > static f(void) > { > // Misra warning: it is not correct to use block scope static > variable. define it at file scope > static u8 Y; > X = ++Y; > } > > sample2 (another catch 22): > void f(void) > { > u8 X; > .... performing some calculations, that guarantee X<2 > switch(X) > { > case 0: doSomething(); break; > case 1: SomethingElse(); break; > // choose between the following warning: > // 1. inaccessible default statement > // 2. case without default statement > default: assert(0); break; > } > } > > sample3 (senseless code damage due to MISRA): > u8 *u8Ptr1,u8Ptr2; > u32 N; > .... some calculations > > // Misra warning: performing pointer arithmetic > u8Ptr1 = u8Ptr2+N; > > // The following replacement help us to decrease warning number > // No warning here! but this is semantically the same as above > according ISO & ANSI. > // It is exactly as (un)safe as the example above and generates the > same binary code: > u8Ptr1 = &u8Ptr2[N]; > > and many other examples - I don't remember them all. > > finally, this is an excellent resume on MISRA stupidity: > http://www.knosof.co.uk/misracom.html > > It is a set of rules, defined by not very clever people (especially > the older MISRA version) and used > by automotive software producers, because it looks nice for the > bureaucratic high-level managment. > > please, for those who do not code using strict misra checker: do not > argue that MISRA is good. Without signifficant changes and > improvements to these rules, it is not more than annoying tool. > Compiler warnings of a good CC are far more useful to prevent bugs at > early stage development.
...and even more so, PC Lint. With a modified version of its MISRA rule set, to skip the more obnoxious MISRA rules.
> And do not wonder if you see buggy embedded software! A precious time > is spent every day to justify lots of senseless warnings.
"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. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://c-faq.com/ comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
On 26 Mar 2007 14:45:23 -0700, disident@rootshell.be wrote:

=== Snipped previous samples ===

>sample3 (senseless code damage due to MISRA): >u8 *u8Ptr1,u8Ptr2; >u32 N; >.... some calculations > >// Misra warning: performing pointer arithmetic >u8Ptr1 = u8Ptr2+N;
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. -- Dan Henry
On 26 Mar 2007 14:45:23 -0700, disident@rootshell.be wrote:

=== Snipped previous samples ===

>sample3 (senseless code damage due to MISRA): >u8 *u8Ptr1,u8Ptr2; >u32 N; >.... some calculations > >// Misra warning: performing pointer arithmetic >u8Ptr1 = u8Ptr2+N;
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. -- Dan Henry
In article <nnsld4-5og2.ln1@fenelon.com>, Pete Fenelon 
<pete@stratos.fenelon.com> writes
>disident@rootshell.be wrote: >> >> It is a set of rules, defined by not very clever people (especially >> the older MISRA version) and used > >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.
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 /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/