Embedded Systems Engineering Standards Column vol 15.2 March 2008 Standards: MISRA-C3 and ISO-C1* By Chris Hills

 

These are my own personal views and not those of my company Phaedrus Systems see www.phaedsys.com which is where the full version of this column, with links etc, resides under the Technical Papers button.

 

We had the first MISRA-C meeting of 2008 and with some new members. The group is now a little larger but not much.  Small dedicated teams work better than large teams of less dedicated people.  It is the second proper meeting looking at MISRA-C3 though it has been called MISRA-C:2010 so we will see how far we slip!

 

After consulting with most of the embedded compiler companies MISRA-C3 will be based on ISO9899:1999 (C99) with the three current TC’s.   MISRA-C is a working standard and has to work with the tools that are in use now, or will be when the next version is published.

 

MISRA-C is referencing the ISO version not the ANSI, BSI, DIN, EN etc versions. Taking the list of changes from C95 to C99 I can see why no one has fully implemented ISO C99.  

 

Having looked around for some additional advice on parts of C99 I find dissention in the ranks of the ISO C panel. Several people who should know what they are talking about, particularly on the things like complex numbers, say it is a right mess and actually broken. This is why there no full, or consistent, implementations of the C99 maths…  It is interesting that many who were on the ISO C panel at the time are now distancing themselves from the decisions made for some parts of C99.. In some cases I know that they were very much against it at the time. Others I am not so sure about however I am not going to dredge up the archives to name names.  BTW I joined the C panel in 1999 after C99 was published.  The UK panel became unpopular for repeatedly raising defect reports!

 

In several areas the C99 standard is so convoluted and confusing and as I discovered last week in places it is unreadable! Some thing such as idempotent types are there because of “compromise”.   I get the impression that the ISO C panel that worked in the mid 1990’s did a lot of “compromise”, not always for the best of engineering motives. Also there seems to be some features added for some small but clearly vocal groups.  Other things were “cleaned up” so there are quite a few “QUIET CHANGES”   Places where the syntax has not changed from C90 to C99 but the behaviour has.  So code that is perfectly legal in C90 is still perfectly legal in C99 it is just that it does something different…..  This is why I asked the compiler companies which engines they were now using. The majority are [partially implemented] C99 rather than C90 [with extensions].  It affects the logic in some places.

 

Thus you had compromise and additions for pressure groups with no one really looking after the mainstream or the large embedded markets where things tend to be mission or safety critical.   One thing I have discovered about ISO standards is that if you write a paper on a topic you can get it registered and discussed. 

 

Then you can get it in as a Technical Report or TR.  Many say that once it gets to a TR it is a forgone conclusion that it will be in the next standard. Some compiler companies, not in the embedded space are saying that some of their library functions are “ISO-C compliant” because they appear in a TR. They also have listed as “Deprecated”   some functions in the current ISO library that their functions could replace. 

 

"Run-Time Library Reference stricmp, wcsicmp.
These POSIX functions are deprecated beginning in Visual C++ 2005. Use the ISO C++ conformant _stricmp, _wcsicmp, _mbsicmp, _stricmp_l, _wcsicmp_l, _mbsicmp_l instead."

This implies whoever wrote the documentation, at least, thought the original functions were POSIX which they are not. They are not even ISO C+ compliant.  They are in a TR   http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1146.pdf  but not yet the standard.

 

 

So it seems that those with time or backing can get almost anything in. The trouble is that most people in the embedded industry are chasing deadlines and are under resourced at the best of times so it leaves the way open for other minority groups to push their requrments. Particularly as there is no need for a C compiler to be ISO-C compliant anyway most are not that bothered.  The main person from the UK who used to attended the international ISO C meetings, a retired secondary level maths teacher, to the best of my knowledge,  is neither qualified nor has any experience in commercial or industrial software engineering.  It is his hobby.  This is partly why there is no open membership of MISRA panels. MISRA wants qualified and experienced people (no I don’t know how I got in either!)

 

The MISRA-C team now has the great responsibility to produce a good and workable third version. The ISO-C99 panel(s) lost sight of their main user base and they have admitted this in the C1* charter for the next version of ISO C.  The ISO-C panel even talked about removing some things where most compiler vendors have not implemented them. I don’t think this will affect MISRA-C as I expect the things ISO will deprecate are more than likely going to be banned by MISRA-C in the first place!  Don’t ask me what will be banned, as the work as only just started in both the MISRA and ISO teams.

 

However I have contacted as many embedded C compiler vendors as I know (If I haven’t contacted you please email me) It is no use writing an industrial Coding Standard  if it does not work with the majority of compilers in use as the ISO-C panel found to their cost.

 

I wondered why some of, what appear to me, less than sensible things in C99, like idempotent types came from.  Why would the ISO-C standard let in dubious things rather than go for better engineering.  I wondered what the approach to software was in other non-embedded areas.  

 

This was answered in part when I was looking on the ACCU mailing list. The ACCU used to be the Assn of C and C++ Users but according to the current members is now just “accu” as they are more interested in ruby and python besides ”no one uses C any more…  “

 

 

 BTW see http://i.cmpnet.com/embedded/2007/September07/0907esdNass07sm.gif

which shows that over 63% of embedded systems use C and it is rising! C++ (22%) is on a slight decline, which surprises me with the take up of a lot of 32 bit devices, but apart from Assembler holding steady (7%) the rest are slowly disappearing.  The accu members appear to be primarily in the IT and finance world where there are “no embedded systems”and they think the few that are out there are 8 bit and run less than 64K of code.

 

 

 

 

 

Someone on the accu list had asked how to teach a teenager to program.  I suggested pencil and paper to work out the goals were (requirements). Then work out how to do it in a flow chart (design & algorithms) then start coding.   The response I got was overwhelming and along the same lines as this one:-

 

I'm trying to remember when I last got a spec... Occasionally I even write stuff down, but not very often.  Especially not for bug reports.  Unless writing the tests is considered writing things down.  It isn't really the algorithm, just the expected behaviour. Just start hacking...  Show the guy the python interpreter, and point him at the python tutorial & website and see what he does...

 

Others said they never did design… they just coded and it is “agile” or “extreme”. As someone said at a conference recently they just seem to invent new buzzwords for hacking. Most had never bothered with flow charts at all, just type the algorithm into the editor and adjust until it works. The best way, they said, is to put the young person in front of a screen and let them play. In the same thread there were comments that the ICT courses at the schools were no use because they contained a lot of “Management C***” and not enough programming. Also what there was used the wrong methods… specifications, flow charts and the like not agile etc.

 

Whilst I don’t like agile as such It does remind me of the spiral model from years ago. Also I have long commented that software is one of the few creative processes that does not seem to use prototypes in development so I like that aspect but not most of it.

 

As I mentioned last month one company I know tends to employ domain experts and send them on a 6 month Software Engineering course to learn to program as they find they have the discipline for the domain and can learn Sw engineering.  “Programmers” they found could not learn the domain to enough depth or have enough discipline really for software.

 

Actually a paper from the Journal of Defence Software Engineering (USA) http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.html
Also talk is in this vein and say that that modern programmers do not have enough maths, formal methods or software engineering skills. Though they seem to think the UK is better served than the US is! 

 

Back to the UK there is a new Corporate Manslaughter Act that comes into force in April. Whilst I have been talking about the Bill for some years but now it is an ACT and becoming law in April I have to be careful. I am not a lawyer! So I can not give any advice on enacted law  but it talks about “duty of care” and the first three clauses start with “An organisation” or “The organisation” rather than an individual or single controlling mind as previously.  It is aimed at companies rather than individuals. Also the penalties are up to 14 years in prison and or 10% of turnover fine.  Note TURNOVER not profit.  Ouch! You can download the act at www.justice.gov.uk/publications/corporatemanslaughter2007.htm   You may want to get legal advice if you do anything that interacts with people if it’s failure might contribute to a fatality.  As I mentioned previously this is not as far as I know retrospective.  Therefore it can only apply to fatalities from the 2nd of April 2008.  However the systems that cause the fatalities will probably have been produced some time ago….  You do have documentation and proper processes for your systems don’t you?

 

There are some exclusions to the “relevant duty of care”. Apparently, and specifically, the military special-forces are excluded. I suppose if your mission is to go someone else’s country, outnumbered 100,000 to 1 and blow things up it is a bit difficult to see what duty of care the government could have. Other than providing the right equipment, logistics, back up and long term medical after care-that is.   Perhaps someone should remind the Chancellor that the Hells Angels were the result of no one looking after the veterans of one US conflict!   However I think the high tech equipment they use would be covered .as will many other more mundane systems since embedded systems are now pervasive.  So think on what the failure of your systems might contribute to.  Do you fancy an investigation in to your development process as Lawyers find some one to blame?

  

 

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