From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f849b,b8d52151b7b306d2 X-Google-Attributes: gidf849b,public X-Google-Thread: 103376,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-28 02:15:50 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!62.164.179.169!not-for-mail From: Peter Amey Newsgroups: comp.arch.embedded,comp.lang.ada Subject: Re: Certified C compilers for safety-critical embedded systems Date: Sun, 28 Dec 2003 10:15:43 +0000 Message-ID: References: <3fe00b82.90228601@News.CIS.DFN.DE> <3FE026A8.3CD6A3A@yahoo.com> <3bf1uvg2ntadvahfud2rg6ujk24sora6gr@4ax.com> <2u3auvogde8ktotlaq0ldiaska3g416gus@4ax.com> <20619edc.0312221020.3fd1b4ee@posting.google.com> <20619edc.0312222106.3b369547@posting.google.com> <45cs9hAbLc6$EAAx@phaedsys.demon.co.uk> NNTP-Posting-Host: 62.164.179.169 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1072606549 14854783 62.164.179.169 ([69815]) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en In-Reply-To: <45cs9hAbLc6$EAAx@phaedsys.demon.co.uk> Xref: archiver1.google.com comp.arch.embedded:6213 comp.lang.ada:3878 Date: 2003-12-28T10:15:43+00:00 List-Id: 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 > 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