Embedded Systems Engineering Standards Column vol 11.7 October 2003 Standards: Why Bother?. By Chris Hills

 

I am currently convenor of IST/5/-/14 the BSI C language panel that reports to WG14 (Working Group 14) of the ISO. This is the International C standards panel. Whether I still am at the end of this item remains to be seen! This month I also have to stress that the following is my personal opinion and I am not representing IST/5/-/14 or WG14 in any way

Recently the panel had to vote on a technical report for adding extensions to the C language specifically aimed at embedded systems. These were some maths extensions, specifically for DSP work, and standard method of doing memory IO

 

Alarmingly one of the panel, who has no embedded experience at all said, "Unless we are going to give detailed reasons why we don't like the proposals and spend time fixing them we should vote "yes!" to this proposal". As he has, by his own admission, no knowledge of the embedded market at all (actually he is a retired school teacher). I was a little alarmed that someone with no knowledge of the subject could decide the fate of a whole sector of industry. Therefore, I sent the proposals off to eight embedded compiler writers. Only one replied and he is on the BSI panel anyway. For the record he was against the proposal. Several other members of the panel who understand the current C standard very well were against the proposal not because they understand the embedded world (though some do) but because they could see problems with the maths model and the current 9899:1999 C standard (C99). The maths extensions were predominately for DSP applications.

 

This brings me on to the main point. It appears that few are bothering with the C programming standards. As I mentioned the most vocal member of the BSI C panel is a retired teacher who has never been a commercial/industrial SW engineer let alone involved in embedded systems. It does not matter on the desktop. They just swear and "Ctrl-Alt-Del". However, embedded engineers don't usually have that luxury. It saddens me, and many on the BSI panel, that the C standard is running away from its users and seemingly becoming irrelevant. I was surprised that seven of the eight embedded compiler vendors approached did not reply. The sad fact is that it appears the C standard is becoming commercially irrelevant.

 

The lack of interest from compiler writers may be because all embedded compilers, except the Tasking Ticore compiler released this summer, and one, non-mainstream desktop compiler still use 9899:1990 (C90) with a few extensions. This is why Hitex UK in association with BSI has made the C90 standard available again at £30 or £50 in a bundle with MISRA-C. Email me if you want a copy. For many projects e.g. where you are using MISRA-C you are required to have the base C90 standard. A copy of K&R is not good enough, even the 2nd edition. And just for information your "ANSI C" compiler will also be an IS0 C90 compiler. ANSI is part of ISO the same as BSI. Note there is a full description of how the standards committees work and the history of the C standardisation on www.phaedsys.org under the SW eng button.

Actually not only do embedded C compilers not follow the current standard but there is only one desktop compiler, and not a mainstream one at that, that claims to adhere to C99. The problem is that there is no penalty for not following the standard. Some of the world's most common compilers take liberties with the language and people still use them.

 

Some of the members of the BSI C panel refer to the "Lawnmower Syndrome". That is to sell a lawnmower in the UK you must, by law, conform to certain standards. Thus, as far as I know, ALL lawn mower manufacturers not only have a copy of the grass cutting equipment standards they also sit on the standards panel. Partly to put in things they want and partly to stop other manufactures putting things they don't want.

 

In the software industry, accepting a few areas, there is no requirement to adhere to any standards. There is a certain well-known compiler vendor who handles // in #defines slightly differently to most of the embedded compilers and the standard. This can cause subtle problems. The programmer concerned had written some code in one compiler and when it did not work in the embedded compiler he assume the embedded one was broken. When it was explained the embedded compiler conformed to ISO-C (on this point at least) his reaction as that ISO-C should follow what ever the other compiler was doing!

 

The problem is: what happens when, as discussed previously, Corporate Manslaughter and or licensing of Engineers comes in and they ask what standards you are working to? You need to show you are doing things properly with certified tools. Whilst for Ada it is not a problem as Ada compilers can be certified, it does not happen any more for C or C++ compilers. At one time, various accredited bodies could certify C compilers. BSI used to do this but the costs were high and few bothered so they stopped doing it.

 

The embedded world will be in a mess if conforming ISO C compilers become "required" especially if the desktop C++ community have their way. Many, including Bjarne Stroustrup, the original author of C++, want C to merge with C++ so that C is a strict subset of C++. This is because there are three languages. C, C++ and C/C++! Most embedded people use C, certainly at the 8 & 16 bit area. C++ is used the 32 area and some 16 bit.

 

However on the desktop, which is predominantly 32 bit, a large number of people use C/C++. This is a strange language that is mainly C++ but uses many C libraries etc. Therefore the C++ programmers need compatibility with C. Their idea is to merge the two languages completely compatible. This, it has been suggested, can easily be done by modifying the C libraries and language to fit "what every one wants" because the desk top community know that no one uses 16 bit systems, let alone 8 bit cpu's any more.

 

The other reason cited was that "all " C compilers are just C++ compilers with a different switch set. It took a lot of arguing to persuade a group of programmers that some compiler vendors still make only pure C compilers even if they do use a C++ compiler to compiler them.

 

There have been several moves by informed groups to make a stand and put together a solid C standard for embedded use that is midway between C90 and C99 that is approximately where most for he good embedded C compilers are now. A good core definition with appendices with useful extensions for things like DSP's , processor specific areas etc. However we al have busy lives and whilst there is no commercial or legal necessity it is likely to remain a proposal until some legislation or threat of legal action makes it a commercial necessity. The usual rules of project control and committees come in and we end up singing along with Roger Daltry … "We won't get fooled again."

 

Some companies use the system. Microsoft, after it's fun with Java, is working with ISO to get the C# standards adopted as a formal standard.

 

Standards involvement is easy. You just email me, the convenor, at chris@phaedsys.org and I put you on two low traffic (usually!) email reflectors and you can turn up at the 4 meetings we have each year. These are at the BSI offices in Chiswick. You even get free parking, coffee and biscuits. This way you get visibility of all new proposals (and bug fixes) for the C standard and a chance to influence them. There are also two 5 day meetings a year around the world. Each panel sends one or more representatives. There is even some DTI funding for this so it can be a free trip.

 

What's in it for you and your employer? It's like being on a constant C training course with the useful information you pick up. Networking, you become part or the international ISO C email reflector. Many names will be well known to most programmers. Also there is the advanced information. For example we are looking at a new proposal from a well-known company who wants to change the entire floating-point maths model. This is because of a radical new design in hardware. The rest of the world will start to get glimpses of it in 6-12 months time I expect. The BSI panel had the first briefing in the UK outside the company. At least there is one company taking programming standards seriously.

 

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