shame on MISRA

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

Reply to
disident
Loading thread data ...

In article , snipped-for-privacy@rootshell.be writes

The author of the link you cite was also involved in the first version of MISRA-C and is taking part in MISRA-C++

And who are you to say this? You hide behind a fake email address. Identify yourself, make the comments again .

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

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?"
Reply to
Pete Fenelon

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 ....................
 Click to see the full signature
Reply to
Paul E. Bennett

What MISRA checker are you using?

Yes, there is a lot of silly things like that in MISRA. It is quite difficult to be 100% compliant.

Yes, this is correct. First of all, an integer should not be used as the switch argument; switches should be used with enums only.

Yes, this is correct. You should not modify, alias or copy the pointers. Work with arrays and indexes only.

So? Should we file the complaint to the UN?

It is better then nothing, anyway.

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

MISRA is not too bad. You just have to get used to it.

Unfortunately, there is no replacement for the common sense, experience, good taste and intelligence (Stroustrup).

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

formatting link

Reply to
Vladimir Vassilevsky

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
Reply to
Al Balmer

On 26 Mar 2007 14:45:23 -0700, snipped-for-privacy@rootshell.be wrote in comp.arch.embedded:

...and even more so, PC Lint. With a modified version of its MISRA rule set, to skip the more obnoxious MISRA rules.

"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
 Click to see the full signature
Reply to
Jack Klein

=== Snipped previous samples ===

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
Reply to
Dan Henry

=== Snipped previous samples ===

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
Reply to
Dan Henry

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     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

In article , Jack Klein writes

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

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

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

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

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.

Never said you were I was addressing the comment to snipped-for-privacy@rootshell.be

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

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.

Reply to
Arlet

Very good point.

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.

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

formatting link

Reply to
Vladimir Vassilevsky

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

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

Reply to
John Perry

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

--
pete@fenelon.com "how many clever men have called the sun a fool?"
Reply to
Pete Fenelon

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

Such as?

Such as?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

In article , Arlet writes

I hope so. That is the intention

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     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

You might think that I could not possibly comment

See

formatting link
for a REAL programmers guide for people who do not want their creativity limited.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

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

--
********************************************************************
Paul E. Bennett ....................
 Click to see the full signature
Reply to
Paul E. Bennett

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     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.