Re: Certified C compilers for safety-critical embedded systems

[Alan Balmer <albalmer@att.net>]

On 22 Dec 2003 21:06:08 -0800, snarflemike@yahoo.com (Mike Silva)
wrote:

>Alan Balmer <albalmer@att.net> wrote in message news:<b5feuv06s2nmpakq0o1b7v0kpd450v3eli@4ax.com>...
>> On 22 Dec 2003 10:20:04 -0800, snarflemike@yahoo.com (Mike Silva)
>> wrote:
>> 
>> >"tanya" <tanya.anne@bigpond.com> wrote in message news:<bs62ph$giu$1@newshost.mot.com>...
>> >
>> >> As for using C, it is a simple language that can be and is used safely by
>> >> many people.
>> >
>> >I think a more interesting question is: given a particular quality of
>> >programming talent and fixed amounts of time and money, how will
>> >software written in C fare against software written in "better" (as
>> >determined by safety-critical industry concensus) languages?  I think
>> >the evidence is overwhelming that it will fare quite badly, meaning it
>> >will cost more and/or take more time and/or and have more residual
>> >errors.
>> >
>> Sounds interesting. Can you provide references to such evidence,
>> obtained under the stated conditions?
>
>I think the Ada and SPARK communities can, which is why I've added
>comp.lang.ada to this thread.  For example, here's reference to a
>100:1 residual error reduction between C and SPARK, and a 10:1
>reduction between C and Ada, with all code having been previously
>certified to DO178B level A:
>
>http://www.sparkada.com/downloads/Mar2002Amey.pdf

An interesting article, though not for the residual error reduction
references, which are simply quotes of claims made by Lockheed, with
no background. However, the author makes some excellent points,
including one I don't see made often enough - that higher level
languages tend to increase abstraction but decrease predictability.
This is countered to a significant extent by using a well-chosen
language subset, like SPARK. In particular, this leads to the
possibility of static analyzers which are, in a sense, the logic
equivalent of lint's syntax checking.

In reference to "those who maintain that choice of programming
language does not matter, and that critical code can be written
correctly in any language", he says "The claim may be true in
principle but clearly is not commonly achieved in practice." Let me
interject that my position is that "critical code can be written
correctly in any language" (actually stronger than I would contend),
but not that "choice of programming language does not matter." I'd
also point out that there is probably more critical code written in
assembler and C than in Ada or SPARK :-)
>
>Some more interesting reading (note that MISRA acknowledges that there
>are better languages than C for safety-critical work):
>
>http://www.sparkada.com/downloads/misracatsil4reader.pdf
>
Sorry, but the MISRA recommendations and guidelines are so poorly done
that I can't accept them as even relevant. This is not just my
opinion, but that of some very well-respected authorities, and has
been discussed here on occasion.

>This document has a table of language recommendations (search for
>"Language Recommendations (IEC 1508)" ).  C is only recommended for
>SIL1, while it is not recommended for SIL3 and SIL4:
>
>https://www.cis.strath.ac.uk/teaching/ug/classes/52.422/programming.languages.doc

This is one in a series of lectures. I would have some fun arguing
with the lecturer on some of his points, but he does include the
referenced tables from the IEC publication (which I'm too cheap to buy
:-)

I think I have to concede that, on the average, code quality can be
better with a well-chosen subset of a higher-level language other than
C. However, it's still my opinion that "average" programmers, as
described in these studies, shouldn't be writing safety-critical code.

Unfortunately, the material presented doesn't give me any idea of the
whole development process - I don't know if the code in question was
reviewed, linted, or even designed before coding ;-) It may have more
to do with other parts of the process than with the language. I won't
argue that C and poor process are often found in the same
neighborhood.

Since a large part of my work is maintenance of legacy systems, I'll
readily agree that the error rate I encounter is horrible. I'll also
claim that error rates of programs I've completely reworked are very
low. Further, most of the errors I find would have been prevented by
good practices, sticking to standard C where possible, and paying
attention to compiler warnings. In fairness to my predecessors, some
of this code was written before the standard, which excuses about 3%
of the problems I find.

Anyway, some very interesting reading. Thank you.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net