In article <e...@4ax.com>, Jack Klein 
<j...@spamcop.net> writes
>On 26 Mar 2007 14:45:23 -0700, d...@rootshell.be wrote in
>comp.arch.embedded:
>> 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.

Thanks. It is not perfect but we hope better than most other options.

I note that the JSF++ was based on MISRA-C

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

There will be a TC and example suite soon and a MISRA-C V3 in a few 
years. Hopefully it will have the same level of improvements between 2 & 
3 as 1 & 2

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

Others have tried but it takes a LOT of work.

The MISRA team meet for 2 full days every 12 weeks and do other MISRA 
work in between. Between us we have access to something like 10 major C 
code analysis tools for testing the rules as well as many decades of 
experience of real work problems and projects. Mostly in high integrity 
and safety critical systems.

The review team is a couple of hundred strong and includes SAE, JSAE, 
JAMA, HIS etc


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

That is fine They are there for guidance. I have always said "You can 
deviate all you want as long as you can stand by your deviations a few 
years down the line in a court of law ."  That usually makes people 
think... which is the best we can hope for.

>Note to Chris Hills:  I am not now, and never have, hidden behind a
>fake email address on usenet.

Never said you were I was addressing the comment to 
d...@rootshell.be


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c...@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Mar 27, 12:46 am, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
wrote:

> > 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 point of the OP was that you can trivially rewrite the offending
expression by the following, equally unsafe code, and avoid the
warning:

u8Ptr1 = &u8Ptr2[N];

Or one could even avoid pointers altogether, and write something like
this, which can be as unsafe as the previous:

N = /* complicated expression */
a = u8Ptr2[N];

The bigger issue is that basically *any* random C program can be
converted into an equivalent program that complies with MISRA rules
(or any other set of similar rules, for that matter). This conversion
process can even be done fully automatically by a suitable tool. Of
course, simply rewriting code into a different syntactic form does
not, by itself, increase the safety.

In the end, the programmer must not just follow the rules, but also
understand the reasoning behind them, and must apply the same
philosophy to the rest of his work. It should not come as a surprise
that a set of guidelines can be subverted by a sufficiently motivated
person.

Arlet wrote:


> The bigger issue is that basically *any* random C program can be
> converted into an equivalent program that complies with MISRA rules
> (or any other set of similar rules, for that matter). This conversion
> process can even be done fully automatically by a suitable tool. Of
> course, simply rewriting code into a different syntactic form does
> not, by itself, increase the safety.

Very good point.

> In the end, the programmer must not just follow the rules, but also
> understand the reasoning behind them, and must apply the same
> philosophy to the rest of his work.

MISRA comes with clear and straightforward guideline documentation. This 
documentation explains the reasoning behind every rule, and suggests the 
whole methodology of the development. Most of the MISRA philosophy is 
just the common sense and good software development practice.

> It should not come as a surprise
> that a set of guidelines can be subverted by a sufficiently motivated
> person.

In this case, MISRA acts as the disciplinary tool forcing the stubborn 
donkeys to comply to the letter of the rules at the least.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

Arlet wrote:
> ...
> 
> The bigger issue is that basically *any* random C program can be
> converted into an equivalent program that complies with MISRA rules
> (or any other set of similar rules, for that matter). This conversion
> process can even be done fully automatically by a suitable tool. Of
> course, simply rewriting code into a different syntactic form does
> not, by itself, increase the safety.
> 

...and the fault with MISRA is...?

> In the end, the programmer must not just follow the rules, but also
> understand the reasoning behind them, and must apply the same
> philosophy to the rest of his work. It should not come as a surprise
> that a set of guidelines can be subverted by a sufficiently motivated
> person.

...But the point of MISRA and such is not to be proof against the bad
guys, but to rein in the prima donnas and "clever" programmers who think
it's cool to write obscure code that does strange things just because
they think they can, and the even worse fools who "don't want their
creativity limited".

(that's a particular thorn in my side right now, having to modify code
from one these idiots).

John Perry

Chris Hills <c...@phaedsys.org> wrote:
> 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.

Indeed, Derek's company does some excellent work and Derek writes some
very trenchant and elegant papers. 

I was referring more to some of the end-user companies involved in
MISRA; I've dealt with some of the automotive companies involved and
been less than 100% impressed with their grasp of the subtleties.

pete
-- 
p...@fenelon.com "how many clever men have called the sun a fool?"

In article <5...@fenelon.com>, Pete Fenelon 
<p...@stratos.fenelon.com> writes
>Chris Hills <c...@phaedsys.org> wrote:
>> 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.
>
>Indeed, Derek's company does some excellent work and Derek writes some
>very trenchant and elegant papers.

Derek is a one man outfit. He was working somewhere else previously 
where some of the other major contributors also came from

>I was referring more to some of the end-user companies involved in
>MISRA;
Such as?

> I've dealt with some of the automotive companies involved and
>been less than 100% impressed with their grasp of the subtleties.

Such as?
-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c...@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <1...@p15g2000hsd.googlegroups.com>, 
Arlet <usenet+5...@c-scape.nl> writes
>In the end, the programmer must not just follow the rules, but also
>understand the reasoning behind them, and must apply the same
>philosophy to the rest of his work.

I hope so. That is the intention

> It should not come as a surprise
>that a set of guidelines can be subverted by a sufficiently motivated
>person.

I know and sadly that is the case with the MISRA rules too. We see 
people trying to comply with the letter whilst subverting the spirit.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c...@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <9maOh.94188$i...@newsfe14.lga>, John Perry <j...@no.spam> 
writes
>Arlet wrote:
>> ...
>>
>> The bigger issue is that basically *any* random C program can be
>> converted into an equivalent program that complies with MISRA rules
>> (or any other set of similar rules, for that matter). This conversion
>> process can even be done fully automatically by a suitable tool. Of
>> course, simply rewriting code into a different syntactic form does
>> not, by itself, increase the safety.
>>
>
>...and the fault with MISRA is...?
>
>> In the end, the programmer must not just follow the rules, but also
>> understand the reasoning behind them, and must apply the same
>> philosophy to the rest of his work. It should not come as a surprise
>> that a set of guidelines can be subverted by a sufficiently motivated
>> person.
>
>...But the point of MISRA and such is not to be proof against the bad
>guys, but to rein in the prima donnas and "clever" programmers who think
>it's cool to write obscure code that does strange things just because
>they think they can, and the even worse fools who "don't want their
>creativity limited".

You might think that I could not possibly comment


See  http://www.phaedsys.demon.co.uk/chris/mistrayc/MISTRAYC.pdf
for a REAL programmers guide for people who do not want their creativity 
limited.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c...@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills wrote:

> You might think that I could not possibly comment
> 
> 
> See  http://www.phaedsys.demon.co.uk/chris/mistrayc/MISTRAYC.pdf
> for a REAL programmers guide for people who do not want their creativity
> limited.

Except that the file could not be opened (even from the web page above it).

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

In article <eubpe9$538$1$8...@news.demon.co.uk>, Paul E. Bennett 
<p...@amleth.demon.co.uk> writes
>Chris Hills wrote:
>
>> You might think that I could not possibly comment
>>
>>
>> See  http://www.phaedsys.demon.co.uk/chris/mistrayc/MISTRAYC.pdf
>> for a REAL programmers guide for people who do not want their creativity
>> limited.
>
>Except that the file could not be opened (even from the web page above it).
>

Very strange as I cut and pasted the link from the web browser....
Can any one else see the pdf OK?

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c...@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/