Re: Certified C compilers for safety-critical embedded systems

[Peter Amey <peter.amey@praxis-cs.co.uk>]

I would much rather concentrate on technical issues here (for example, 
why deep static analysis of _any_ general-purpose langauge is 
impossible; or, why systems of integrities in the better-than 10e-6 
failures per hour class _require_ deep static analysis); however, I 
can't let Chris Hill's petulent little rant below pass unchallenged!

Chris Hills wrote:
> In article <20619edc.0312222106.3b369547@posting.google.com>, Mike Silva
> <snarflemike@yahoo.com> writes
> 
>>Some more interesting reading (note that MISRA acknowledges that there
>>are better languages than C for safety-critical work):
> 
> 
> That will change. 
> 
> 
>>http://www.sparkada.com/downloads/misracatsil4reader.pdf
> 
> 
> Praxis has a vested interest in not letting C be used for SIL 4

Praxis has a long-held commitment to using the best technology available 
and to advancing the state of the software industry as a whole.  Our 
objection to using C for SIL 4 is that it is unsuited to that task.  The 
majority of the proponents of the use of C in this role are C tool 
vendors; are they too governed only by vested interest?

> 
> BTW 
> slide 3 is erroneous.
> slide 5 is also erroneous.
> 

> AFAIK Praxis are not "involved" with MISRA-C they may have been some
> years ago in the original version but much work has been done since
> then. AFAIK they have not taken much, if any part, in this.
> 

Neither slide is erroneous. They are clearly dated 2002 and are factually
correct for that date.  We had two members on the original MISRA-C 
committee
and attended every workshop and committee meeting until the beginning of
this year.  We still monitor the mailing list and will contribute again 
when
we have something to say.

> AFAIK they did not make their SPADE C results available to the MISRA-C
> working group who for the last 3 years have been working on MISRA-C2.

Wrong.  We did.  Unfortunately the rather stern view we took of what was 
needed to make C fully-analyseable (basically, a Pascal subset in C 
syntax) was not seen as being compatible with the apparent aim of the 
comittee: as much C as possible with the minimal restrictions needed to 
plug the biggest holes.

> 
> Praxis don't have a unique view of MISRA-C.  They are one of many who
> were involved in MISRA-C1. They are not one of the main companies who
> were promoting and working with it in the last 5 years.

The slide clearly states that this is Rod's personal view and he (with 
appalling semantics) qualifies the "unique" with "almost".  I think is 
is at least defensible to say that Praxis's experience as: implementors 
of world class critical systems, language designers; and tool vendors 
_does_ give us a different (even unique) perspective from most other 
contributors none of which (AFAIK) has done _all_ of these things.

> 
> Slide 6 is interesting. The quotes are out of context and misleading.
> The Praxis presentation is clearly written with a (commercial) axe to
> grind. I was at the MISRA-C 2002 forum. In fact I did one of the
> presentations that has been misquoted.... 

Perhaps you can recall the context in which Less Hatton's shack/swamp 
comment can be interpreted in a positive way?

> 
> As it goes on they rubbish C and surprise surprise come up with a
> solution that is their tools.... :-) 

We don't rubbish C.  We rubbish magic where logic is to be preferred. 
We have well-articulated reasons for saying that C is not well suited 
for constructing high-integrity systems.  The proponents of C for this 
purpose never seem to present their reasons.  All we ever hear are: 
"there are lots of C programmers around"; "we only ever employ the best 
people and they don't make those kinds of mistakes"; and, the falsehood, 
"C, with suitable support tools, is as good as anything else".

We don't take this view because we have alternative tools, we have 
alternative tools because we take this view!

> 
> The Ada (tools) community must be rattled if it needs to spend time
> trying to rubbish MISRA-C. Perhaps it is just sour grapes as they no
> longer push a MISRA-C tool? 

Again we are not trying to rubbish MISRA-C.  We continue to believe that 
  it is useful enterprise.  If people want to use C for smaller, 
safety-related systems then having a widely-supported coding standard is 
a "good thing".  We will continue to rubbish the promotion of that 
coding standard to application domains for which it unsuitable.

We no longer promote a MISRA-C tool because the widely-differing 
behaviour of our and competing tools and the high level of ambiguity in 
the MISRA-C rules showed that the market was too immature for tools 
claiming to enforce MISRA-C compliance.  We preferred, in that 
situation, to say nothing rather than make claims that could not be 
defended by logic and by reasoned argument.  I hope that MISRA-C2 will 
be  better; however, my long experience of designing unambiguous and 
analyseable programming languages leads me to believe that it won't.

> 
> Since the 2002 meeting MISRA-C2 has been reviewed by the SAE and JSAE
> several major automotive companies, aerospace companies, also  members
> of WG14 the ISO-C panel and met with approval. MISRA-C2 will be
> available at the end of Q1 2004
> 
> 
> 
>>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.do
> 
> 
> Yet  C is used in some of the highest integrity systems around. Other
> languages that are recommended hardly exist and certainly not on many
> platforms.
> 
> Empirical evidence and a glance at 61508 may require a change in the
> table D2.... BTW table D2 in the lecturers notes is NOT in 61598.
> 
> In CEI/IEC 61508:1998 Part 7 Table C1 (page 79), yes I do have my own
> copy of 61508, all 7 parts. We find a similar table to "D2" above:
> 
>             Sil1   Sil2   Sil3 Sil4
> Ada          HR    HR      R    R
> ADA (subset) HR    HR      HR   HR
> C            R     -      NR    NR
> 
> as expected  BUT
> 
> C (subset, codinng standard and static analysis) 
>              HR   HR      HR     HR
> 
> 
> So whilst straight ADA *is* better than vanilla C. No one would debate
> that!  Spark ADA is no better than C with a subset, coding standard and
> using static analysis....  IE much the same constraints as SPARK ADA has
> over ADA...

Fundamental misconception.  SPARK is wholly unambiguous and therefore 
analyseable in a formal and mathematical sense.  An un-annotated subset 
of C _cannot_ have this property.  Analysis of such a language can, 
therefore, ony result in the _detection_ of certain kinds of error, it 
cannot _prove_ that they have been eliminated.

> 
> I know of projects using C in Railway, space, aero and medical projects.

Use, even widespread use, does not imply suitability.

> 
> PASCAL and Mod2 are mentioned but you will be hard pressed to find tool
> for these for many targets. BTW is there ADA for the PIC, AVR and 8015?
> 

Agreed.  Modula-2, in particular, was a nice language from which a 
secure, SPARK-like sublanguage could have been constructed.  Pity it, 
unlike Ada, never achieved critical mass.

> I come back to my comment previously that the ADA tools vendors must be
> worried if they are spending this much effort trying to rubbish MISRA-C
> which is an automotive guide.  Though it has gained widespread use
> outside the automotive industry due to those involved with it.
> 

I have pooh-poohed this pooh-poohing enough already!

> 
> Regards
>         Chris
> 

have a Happy New Year


Peter