It is an accepted fact that electronics and, by association, software have pervaded our lives. And we can assume that the vast majority of safety systems today are based on some form of electronic control. So it is a bit worrying to hear an independent safety consultant claim that most critical software has been built ‘using methods that aren’t fit for purpose’.
The consultant is particularly scathing regarding the use of C as the de facto programming language. He believes C is weak and, by implication, has no role in safety critical software. In fact, he is not entirely complementary when it comes to MISRA C, the variant used by the auto industry, among others, to bring more stringency to bear.
But his criticisms move beyond C to address the whole approach to the question of safety critical system development. He despairs, for example, at the decline in the use of the formation specification. He also sees weaknesses in the way in which systems are defined; in his opinion, the way boundaries are drawn are defective. When systems are defined, he contends, people forget there will be users and those users will be inside the system.
So we have to ask whether things are as bleak as they appear. The answer has to be no, although the points made are important. In the opinion of the Safety Critical Software Club, ‘there aren’t as many accidents as there used to be, because we can do lots of things to avoid problems’. But the Club admits, despite all this, accidents still happen.
And accidents happen not only because systems are becoming increasingly complex, but also because of the interactions with other systems and with people. Exploring every possibility is out of the question, but it is incumbent upon engineers to use every possible tool available to them and that includes using a language like SPARK, instead of C.
For more, go to bit.ly/vOeDVq
What do you think? Are things as bad as implied?
Catcatcat
Проблема не в Си как языке программирования, проблема в
человеке как разработчике. Недостаточно знать язык Си, надо еще понимать, как
он компилирует исходный текст в машинные коды.
Два разных разработчика использующие один и тот же
компилятор получают совершенно разные рабочие коды с совершенно разной
работоспособностью.
Я считаю для получения профессионального разработчика на Си
необходимо перед этим пройти стажировку на ассемблере.
Гена Чернов
google translation
The problem is not in the C programming language as a problem in
man as a developer. It is not enough to know the C language, we must also understand how
it compiles the source code into machine code.
Two different developers using the same
compiler are completely different working with completely different code
for work.
I think for the professional developer in C
necessary before an internship in assembler.
Gene Chernov
michaelkellett
I'm always amused by diatribes against C which usually, like Tom Anderson's take the form of "C is awful- it would be much better if everyone used X".
There are several reasons why C is used so extensively (and of course in some cases inappropiately) but not the least of them is it's widespread availability which in turn is a function of its low compiler complexity.
You can get a C compiler for almost anything and you can good good C compilers quite cheaply for most things.
If you insist on using X (which might be SPARK) the choice of targets will be compromised (which may or may not matter).
Anderson may well be right that C is not the best choice for systems requiring the highest integrity (although I would suggest that it is far from the worst problem) but that doesn't mean that C is not a good choice elsewhere.
Anderson's arguements would be more persuasive if they were backed up with some real evidence - how many accidents could have been prevented by using SPARK rather than C ? What would be the cost of using C less and something else more ? How would that comapre with the cost of better system specification - etc etc.
Michael Kellett