Summer is here and MISRA-C3 is on the horizon! We have a draft for review!  Now before you get too excited there is a lot of work to do before a published version.  Review feedback has usually caused some small but often radical changes. We are hoping to publish the final version in 2012. 

 

If you would like to review and provide feedback to the MISRA C3 review draft details of how to register your interest are available at http://www.misra.org.uk/News/tabid/59/Default.aspx

 

However, we will not just be passing out copies to all and sundry.  You will have to complete and sign a form. We will ask for some information to see if you have relevant experience. That is ideally real world experience of high reliability and critical systems. MISRA-C is a guide for real world projects.

 

Contrary to some myths MISRA-C long ago ceased to be an automotive standard but has users across many industries for example aerospace, defence, medical, communications, rail, industrial control and even nuclear! We would like reviewers from all those areas and others. Tool vendors are welcome but please do so openly not using home email addresses. The MISRA Project Manager sanitises the identities so the MISRA-C team can have no bias.

 

We will send out the review package to the selected reviewers plus a spreadsheet with a fixed format so we can do some automated processing of results. The review period will be fairly short (three months)so the team can get on with collating the results.

 

Note the PDF will have the name of the reviewer embedded in it to help ensure that the draft does not re-appear on ebay!

 

Please note that the drafts can not be taken as an indication of the next release as the review process can cause a rule to be completely revised. I write this whilst sitting in a MISRA-C meeting and I can say that a lot of thought goes into these rules. It is a question of balancing many competing and often conflicting requirements. This is why we welcome review comments where things are finely balanced for some rules. 

 

We have also have input on the MISRA forum http://www.misra-c.com/forum/ where you can discuss any of the rules.

 

The main thrust of MISRA is to make code clearer and less prone to errors. By default it should be more maintainable. However portability is not a priority as most critical systems are very closely bound to the hardware and MCU architecture. Also most embedded systems are not often required to be run on multiple systems.

 

It is looking like there will be no exemplar suite with C3. There are several reasons for this.  Firstly the sheer amount of work involved:  It is not a trivial task to produce. There are problems of crosstalk between rules and which examples to show, both positive and negative.

 

Then we have the problem that some tried using the exemplar as a test suite.  The Exemplar suite is some 50,000 plus tests short of a test suite and should never be used as a test suite.  It is in no way exhaustive on either positive or negative cases and does not take into account how any tools report MISRA rules.

 

It was discussed asking the community for examples to be sent in however the work required in setting up guidelines for this, which would require a style guide (which the MISRA-C team definitely don’t want to do!) and requirements guide and administration of the process, not to mention testing, simply amplifies the amount of work involved.

 

A related item, that caused much warm discussion in the team recently, was requiring ALL libraries, including system and 3rd party, to be MISRA compliant: Should this be a required rule, advisory or in the process part in the first 5 chapters?  Also should this apply to the visible parts only?  Ie only the header files where the library is supplied as a binary.

 

One view for making it a required rule should mean users will put more pressure on compiler and middle wear suppliers to, at least, make their header files MISRA-C compliant. Talking to some compiler companies they say that to make their libraries MISRA-C compliant will be along job (one said about a decade) and be done as part of the maintenance phase if there was pressure from users to do it. With no pressure from users it may never happen.  This is understandable as retrofitting MISRA-C into a project is not as easy as you might think.

 

The discussion also looked at libraries supplied as binary, where the user does not have the source. Should the original source be MISRA compliant?  Ideally yes, but does the user need to be able to show this? Many 3rd party libraries are only supplied in object form (and source for the header files). Seeing the source code usually costs and arm and a leg.

 

However new libraries are another matter and should be MISRA-C compliant.  This is something we would like some input on. Either to me or to the Forum http://www.misra-c.com/forum/

 

For the review information go to http://www.misra.org.uk/  and hit the NEWS tab. The next MISRA Matters Column will be due around the end of the Review period so we should then have some idea of a release date for MISRA-C:2012 An event more widely anticipated than the Olympics!

 

 

 

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

 

> MISRA Index

 

> MISRA-C

> MISRA-C++

> MISRA-AC

 

> MISRA-SA

 

> MISRA-Matters

 

> MISRA-Gallery