Title: Francis' Scribbles

Scott Meyers recently posted a request to comp.lang.c++.moderated for information about any current uses of C++ in safety critical programming. I am not going to report on the resulting thread other than to say that there is one EC++ (embedded C++) compiler (DO-178B Level A certifiable Embedded C++ (EC++) for its safety-critical INTEGRITY 178B RTOS) that meets pretty stringent requirements for use in a specific environment. It will come as no surprise that this compiler is based on the EDG front end coupled with the Dinkumware EC++ Library.

The language used for safety critical programming worries me far less than the human beings using it. This is the issue that I want to address here.

If you want to work in the UK on gas (note that this is not 'gas' in the US sense of the word) central heating systems you cannot legally do so without certification. Going out and buying a fist class set of professional tools that meet the BSI standards for use with gas appliances does not even start to turn you into a gas central heating engineer, nor should it.

Joining a professional body for plumbers is not enough either. You need competence as a plumber to deal with a central heating system, however you need something more before you are legally allowed to touch a customer's gas appliances; you must be CORGI registered (for more information see http://www.corgi-gas-safety.com/section_about/ corgi_council.asp). I have no doubt that there are many people who are competent to work on gas central heating systems who are not CORGI registered, however these people cannot legally do any work on such a system. Any professional (as opposed to cowboy, fly-by-night) plumber would know what the limits were on his work; no CORGI registration, no touching gas appliances.

Notice that there is no requirement that those designing gas appliances be registered or even have any professional qualification. Their designs will have to be tested according to the standards laid down by their National Body.

Who writes those Standards? People who jointly understand various safety aspects of using gas. It would be entirely coincidental if any of those people were CORGI registered. The collective knowledge of the committee writing a standard is important and so such a committee would benefit from being widely based.

Now start applying the same ideas to programming safety critical systems.

I find it disturbing that we do not yet have an adequate form of certification that covers both the basics of programming safely and requires endorsement for specific computer languages.

Having a certified EC++ compiler for a specific RTOS is great but that in itself is only a very small part of the problem. The human beings in the mix cause the problems. They (as a team) need a full understanding of the problem domain and the tools they are using.

Using some set of coding guidelines such as MISRA C does not turn an ordinary programmer into one that can be allowed to deal with issues where human life is at risk. I contend that anyone who believes that the following code is safe and guaranteed to output 5 is not qualified to write guidelines for use of C in safety critical contexts.

#include <stdio.h>
int main(){
  int i = 2;
  int j = (i++) + (i++); /* A */
  printf("%d", j);
  return 0;
}

A full understanding of C is certainly achievable and anyone working on safety critical C code should have that level of understanding as a pre-requisite.

We need development tools that work as described and generate correct code from our correctly written source code. We need guidelines (preferably ones with tools to enforce them) to avoid problems caused by implicit problems in the language being used. Above all, we need programmers (software engineers if you insist on being grandiose) who fully understand what they are doing and what their code means. A competent programmer will never confuse undefined behaviour with unspecified behaviour.

We need guidelines that prohibit code such as that in line A in the above. However, we also need the programmer to understand why such code is forbidden and that no number of parentheses will fix it.

We also need programmers who do not think that testing will demonstrate that code is safe. All that testing will do is detect some faults, it will not prove that the code is fault free.

I do not need a professional qualification to understand these issues, nor do you. Yet it seems that quite a few people with professional qualifications do not understand them. At that point, it is fair to ask what the value of a professional qualification is.

I recently purchased a download version of ZipMagic 9.0. My experience highlights a serious weakness with such purchases and validation.

In order to install the application I have to type in the serial number. Unfortunately despite having been supplied with three different serial numbers, none of them allow me to install the product.

What is worse is that the supplier (Allume) has failed to respond to my emails. Sales decided it was not their problem and Technical support seem to have nothing to say after I supplied them with the information they asked for.

I wonder how many readers have had similar problems with either this product or other ones.

Problems with initialisation have been of concern to those responsible for working on the next version of the C++ Standard. Have a look at the following code and comment on any possible surprises.

#include <iostream>
struct X {
  int i;
  X(){}
};
struct Y: struct X{
  int j;
  Y(): X(), j() {}
};
Y y = Y();
int main(){
  std::cout << y.i << std::endl;
  return 1;
}

Note that there is more than one problem with the above code.

Well the problem is that I have run out of a ready supply of little coding surprises and problems. It is time that you got involved. Please send in at least one coding surprise. If you do not have any then I guess you do not actually do much programming.

The surprise can be in any of the programming languages that are used regularly for application programming (C, C++, C#, Java, Python etc.)

I wrote the above in my last column. Sadly, there has been no response. I cannot believe that none of you has anything to offer so perhaps you just think yours is too trivial for consideration. In my experience, there are no trivial programming surprises.