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 <1...@n76g2000hsh.googlegroups.com>, 
d...@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     /\/\/\/\/
/\/\/ c...@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

d...@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
-- 
p...@fenelon.com "how many clever men have called the sun a fool?"

d...@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://p...@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..
********************************************************************

d...@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, d...@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, d...@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, d...@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, d...@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 <n...@fenelon.com>, Pete Fenelon 
<p...@stratos.fenelon.com> writes
>d...@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     /\/\/\/\/
/\/\/ c...@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/