- | Home |
- Company |
- Contact |
- News |
- S/ware Eng |
- Standards |
- Academic Support |
- Documents |
- | Requirements |
- Validation |
- RTOS |
- Analysis |
- Software |
- Resources |
- Products |
 |
MISRA-Matters Column
|
 |
Happy New Year! I write this in November whilst heading home from the MISRA/SCSC conference. If you can remember that far back, that day was the first serious snowfall of the winter. Chris Tapp, the MISRA C++ Chairman, heading back to a village near Durham was not expecting to get his car out of Durham Station car park at the end of his train journey!
We can predict many things in life. We can easily adapt and work around many things. I know from living in Munich for a winter that the Bavarians take snow and ice in their stride yet in the UK we seem to grind to a halt with just a couple of centimetres of light snow.
The MISRA conference was interesting as it showed similar trends. Questions to some of the speakers showed that some people were making great strides with software engineering processes and software development whilst, during the panel session, some asked questions we all thought had been answered a decade, or two, ago. Questions like “How long should a function be?” Yes, someone really asked that question! Actually, that is an easy question to answer! It should be the same length as a piece of string…
Among other questions asked were: “What is a reasonable number of deviations in a project? “ I refer you to the length of a piece of string again.
MISRA guidelines provide engineering guidance. They cannot cater for every variation. The main C language test suites contain over 80,000 tests…. Do we want 80,000 MISRA rules?
Someone said he thought there would/should be 2,000 rules in the next MISRA-C. However I note the “someone” was not on the MISRA-C panel or intending to write the rules or the test cases for them!
If MISRA-C or MISRA C++ for that matter had 2,000 rules who would read it? Would we be creating a standard that nobody but tool makers would read? The whole point of the first MISRA-C is that it was readable by the average Engineer. More to the point, it provides guidance that people read and understand so they can make informed decisions, not something to follow blindly and just “tick the box”.
Mike Hennell (member of the MISRA-C panel) in his workshop asked: Should we use rules, or rules of thumb? One rule of thumb is to put the smallest types in an expression the furthest right. There are other rules of this type. The problem is that, as mentioned above, you need to understand the reasons for doing it.
There was also a question as to should we have rules covering the ISO C constraints (of which there are 99 at the top-level, more if you split them up) or is this something a static checker should just do anyway? Opinions are divided on this. What do you think? Answers to the MISRA Forum.
A question that was left hanging, and perhaps you can help with this, is: Which rules give most “bang for the buck” – is there an 80/20 principle? Have you or your organisation done any research on this? If so we would be delighted to hear about this. Perhaps we can start a discussion on the MISRA-Forum? Are there some rules that consistently deliver good results? Clearly this is going to vary depending on application but we might find a core of rules that deliver a good “bang for the buck” across most developments.
Another question which got some thinking was: What are the differences between embedded and non-embedded use of MISRA C or C++? When MISRA started this was irrelevant. Now with the use of OS like Windows and Linux in automotive infotainment systems and the line between embedded and IT blurring the question is valid. MISRA-C and C++ will continue to aim at the embedded use but if anyone is using MISRA-C or C++ for non embedded use please let me (or the MISRA-Forum) know how you get on.
One interesting point came from Darren Sexton of Ricardo in his presentation on MISRA-C and auto-coding. He asked: “How well do tools actually check the rules?” Darren’s presentation suggested 50-60% coverage was the norm. Whilst one of the MISRA team (not on the MISRA-C or C++ WGs) agreed with that statement many of us on the MISRA-C team recorded a higher test rate. Several of the tool vendors said, and had test results to back it up, that the tools can check 85%+ of the MISRA-C rules. Part of this comes down to definition.
Not all the rules are amenable to static analysis and, of those that are, not all are statically enforceable in general. Some tests I have seen say “does not catch all instances” I’d therefore hope that any analyser, when presented with all the source, could check at least 75% of all the MISRA-C2 rules.
The reason for the change is that 75% are theoretically statically enforceable (with all the code visible) and 15%, even with all the code visible, cannot be statically enforced.
One issue that MISRA constantly battles with is that C and C++ are very flexible and, as we discovered with the MISRA-C Exemplar Suite, we cannot produce a case for every eventuality. Indeed the standard C language test suites run to some 80,000 test programs. It is possible that the tools can catch most of the problems but you can still write obfuscated C or the odd case where it will get past a tool. This is why MISRA-C in 1998 implicitly recommended the use of static analysis with MISRA testing. MISRA-C:2004 made this explicit and I expect MISRA-C3 will highlight the use of static analysers that also check for MISRA rules.
The problem we are seeing is the tick box mentality where, due to customer requests, compilers are adding MISRA (C/C++) rules checking. People are doing this rather than full static analysis. This is wrong. MISRA-C/C++ checking should be part of static analysis not compilation. When it is part of compilation only the MISRA rules are checked and there us usually no static analysis. The compiler is a syntax translator. Static analysis is there to check for legal but dubious constructs and MISRA- C/C++ is a sub set of this analysis.
Among the presentations on the second day David Crocker gave an interesting view of modular verification. This method uses a subset of MISRA rules. This may sound enticing but other requirements such as pre and post function contracts ensure that the omitted rules should not be a problem. There are no short cuts to producing reliable software. However this approach may be of interest where you have multiple teams producing modules for a project. As with all software engineering, it requires some thought.
Well that wraps it up for another year for me and is the start of the year for you. I still have Christmas to look forward to but what does the New Year hold for us? I hope that programming will grow-up into Software Engineering. I know I keep saying that! However, the signs are there. Remember MISRA can only help the well-being of your project as part of a calorie-controlled process.
Eur Ing Chris Hills BSc CEng MIET MBCS MIEEE FRGS FRSA is a Technical Specialist and can be reached at This Contact
Copyright Chris A Hills 2003 -2010
The right of Chris A Hills to be identified as the author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988