MISRA-Matters Column
|
Those of you who have read my other columns over the last decade will know that in the summer column I get a bit reflective and philosophical. If there is no pressing news I will do the same here for MISRA.
However, there is one item of news: MISRA has a new look web site. http://www.misra.org.uk/ It is more than a marketing makeover. As well as a step change in technology, it is no longer frame based, we have a completely new structure to it, there is a lot more information and the facility to add more easily as well as, of course, the new look and feel. Many thanks to David Ward for his work on this, not something he was expecting to do when he took on the role as MISRA Project Manager. In fact the web was scarcely out of research labs when MISRA started.
Do take a look at the new web site there is a lot of new information. Also we are continually adding more to it. The good news is you can now book mark or link into specific pages. Pages such as:http://www.misra.org.uk/News/tabid/59/Default.aspx for information on the Safety Critical Systems Club Tutorial & Seminar in collaboration with MISRA. An event reflecting the wider use of MISRA guides in the safety critical and high reliability world. This is an event you will not want to miss!
The value of this type of seminar usually far outweighs the financial cost of the day. You learn things, though personal interaction, that are not in books or on the internet.
Coming back to the philosophical and reflective…. When MISRA started it was completely UK Automotive, hence the “Motor Industry Software Reliability Association”. However, the MISRA languages guides have escaped from the global automotive industry, let alone the UK motor trade, to be widely used in very many other fields. Many in the MISRA language teams felt it was time to remove the expanded title from web site, except on the areas that are still principally automotive. Trenches were dug and barrages of constructive discussions commenced.
The argument for dropping the full title was two fold. One that in several of the MISRA teams there was more input from many other non-automotive industries that use MISRA guides, aerospace for example than automotive. The second reason is far more interesting: There had been several cases of people dismissing the idea of using MISRA language guidelines because the projects were “not automotive”…
Why would people not be interested in making their code safer? One thought was that the MISRA guides might have rules that were not appropriate, many safety standards are [automotive] industry specific e.g. MISRA-SA and IEC 26262.
However, the use of unsafe constructs in C or C++ is unsafe no matter if it is in an automobile, a microwave cooker, aircraft or an off-shore drilling rig. In fact there is no reason other than perception for not using MISRA on any C or C++ development.
I think I made the same comment in 1998 when the first MISRA-C came out. Why wouldn’t you use MISRA-C or C++? Hence the move to drop the expanded “Motor Industry “ tag on the front page and some parts of the web site purely to shift mental preconceptions.
Anything that makes C or C++ safer is a good idea. Sub sets and static analysis are shown to have huge benefits. So why wouldn’t you use a [MISRA] sub-set and static analysis? IEC 61508, the generic non automotive, standard requires it.
The MISRA guides make passing reference to static analysis saying that: your static analyser should check as many MISRA rules as possible. The implication that you should be using a static checker anyway. This is based on the mountain of positive evidence, over the last 30 years, that static analysis for C is one of the most cost effective ways of eliminating bugs. Not just for critical systems but any C or C++ system. Most static analysers can now more or less automatically enforce MISRA rules. Yet most programming in C still do not use the most cost effective way of making the system reliable and saving debugging time. Why not? Post your answers and comment to the MISRA Forum please. Recently a question came up on the MISRA forum that basically said MISRA C bans the use of errno [because it is poorly defined and implemented] but if I don’t include errno.h and define my own errno (the example was “int errno;” is that OK for rule 20.5? This is a trick question and I trust no one even thought about it! MISRA-C Rule 20.1 (and a rule in most other coding standards) says: “Reserved identifiers, macros and functions in the standard library shall not be defined, redefined or undefined”. The rational for that rule mentions errno in particular. The example code given in the question also broke many other MISRA rules causing one respondent to give a fairly blunt response. I can understand why, if not approve the language and phrasing. What we have seen over the years is people trying to circumvent the letter of specific rules rather than trying to understand the sprit of MISRA C or C++ and the intent of the rule. So read the rational as well as the headline rule. Had the poster written “uint16_t errno = 0;” (rather than int errno;) and not used the // comments it would had shown that (s)he was normally writing MISRA-C compliant code. I know snippets of code to illustrate a question are usually not meant to be compiled but it is no excuse for writing the parts that are there as non MISRA compliant. It should be the natural thing to do. If MISRA-C (or C++) is good practice then you should write in that style normally. i som tims wrt in txt spk on a mobl fone bt 4 pblikatn i wrt propr. If I did not do so you would all be deluging the editor and myself with emails of complaint. So why not with C code? If the answer is “because it is easier” then you need to train yourself to do it the better way automatically. It really does save time in the long run and as most other professions will tell you time == money. Think about it. Again answers and comments to the MISRA-C General questions forum http://www.misra.org.uk/forum/ Enjoy the summer and take a break: The mind needs it. As they say a change is as good as a rest. For a change try the SCCS/MISRA seminar later in the year. Details onthe MISRA web site. Author Details and contact 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