Certified C compilers for safety-critical embedded systems

Who said anything about compilers *fixing* things? Who said anything about providing excuses? Would you argue against using lint for the same reasons? In spite of what we all read on usenet, there are no perfect programmers. We should welcome any tools we can use to catch mistakes, even though no tool will catch every mistake.

I tell my boss all the time that C is a garbage language, and that using it (with imperfect programmers, the only kind they've been able to hire) costs the company time and money. Inertia is a powerful thing, but they're starting to listen, just a bit.

Mike

I may be mis-interpreting you, but it seems you are saying that the tools and the process are more important to safe code than the people using them. I disagree.

It's not the language that's garbage, but your programmers. As it happens, I have an excellent example in hand - a project which has several components on Unix, written in C, and one component on Windows, written with Delphi. For the last couple of weeks, the project has been beating its head against problems in the Delphi code, whereas the C code is WAD.

I'm not blaming Delphi. Don't expect your programmers to start producing good code because you give them a different language.

... snip ...

However Delphi is effectively Cified Pascal, with most of the C insecurities reinserted and most of the C shorthand removed. It's main claim to fame IMHO is a relatively clean way of creating Windows GUI interfaces. I consider it requires a great deal of expertise to use both cleanly and accurately, although not as much as C or C++.

No, I'm simply arguing (along with others here, it appears) that all the above have an impact. And I am agreeing that CPU horsepower (in the form of better compilers for better languages) should be used to catch as many problems as possible, as early as possible in the development cycle, irrespective of any other factor such as process or programmer ability.

We'll just have to disagree on this one. :) Our programmers are the same as all the millions of programmers who have, by their imperfect human nature, nurtured the lint band-aid on top of the C sore. C simply makes too many wrong choices to be a good tool for use by normal human beings. That it has been used heroically in many cases is a tribute to the heroes, not the language.

Mike (C programmer for 25 years)

... snip ...

I suspect one of the important reasons that C has won out over Pascal as the primary application language is that it simply complains less. This allows the sub-standard programmer to write things, and get error free compiles. The fact that the result doesn't work, or isn't portable, is not his fault. After all, it compiled, didn't it?

Of course the fact that the most popular so-called Pascal system did not implement Pascal may also be connected. This lost the Pascal portability advantage.

I think you'll find that Airbus, Boeing etc. disagree with you. Which would you rather fly on - an aircraft whose fly-by-wire code was written by a single genius with no process or tools, or a group of well-drilled dullards whose every step was automatically checked and double-checked through a rigorous process.

These are the two ends of the scale, obviously, but I know which plane I'd prefer to fly on.

Cheers TW

Me too. One where the man sitting up front can override the bloody software if he wants to! :)

Mike Harding

IIRC the design (at the time) had to be synchronous so that it could be proven correct by automatic proof tools and the speed was limited to a few MHz because of this. Another problem was that they used a diamond on sapphire process (for radiation hardness) that was complicated and had very low yield.

George ============================================== Send real email to GNEUNER2 at COMCAST dot NET

I once had the misfortune to work on a safety critical project where the use of interrupts was not permitted. That was done because it was not possible to prove mathematically that code containing interrupt service routines was correct. Instead, polling was used. The resulting increase in code complexity to ensure that asynchronous events were serviced in a timely manner was frightening. There is no doubt in my mind that the use of interrupts would have been safer. As for using C, it is a simple language that can be and is used safely by many people. I would venture to say that if someone can't use C safely, then they certainly shouldn't be using a more complex language like C++. As for Pascal, Modula 2, etc., IMHO they are next to useless in that interesting place where software meets hardware.

Tanya

use

code

What a breath of fresh air! Thank you, Tanya.

-- Peter Bushell

Me too :)

Mike Harding

Can you explain, possibly enlightened with an example, why Pascal would be next to useless in that interesting place where software meets hardware?

Meindert

... snip ...

That is certifiably insane. However I can see banning edge triggered interrupts.

... snip ...

Far from it. The file abstraction of ISO Pascal allows almost anything to be connected (and I have done so, from interrupts to networks to devices). Those file drivers are probably not going to be written in Pascal. This serves the function of splitting off system dependencies very nicely, and preserves the safety aspect of a better structured language.

Cs problems largely arise out of making it a structured assembler, capable of coping with anything at all.

I don't think so (though that doesn't mean you're wrong ;-)

I did most of my academic programming (from around 1979-1983) in Pascal. I had studied other languages (as required by the curriculum) and liked nothing else as well (though Lisp was fun).

My earliest embedded programming projects were in assembler (various

*The* number one thing that led me to prefer C for embedded programming was the explicit bit manipulation operators. In particular, I remember a terribly frustrating (non-embedded) application (written in Pascal) where I needed to mask out bits in unsigned values. There were no standard operators or library functions. I vaugely remember a horrible collection of case statements and looping constructs. It wasn't pretty.

The number two thing was the (mostly illusory) "efficiency" of the language -- the "fact" that it was really a "high-level assembly language.

The number one reason I've stuck with it is the ubiquity of C. The only processors I can think of that don't have at least two sorta-C compilers targetting them are 4-bitters.

Another problem I had with Pascal was the loss of modularity. The entire program resides in a single text file. That may no longer be true, but it was back in the early '80s.

I would have liked to have tried Modula-2, but I haven't ever had the chance. The only "Modula-2" compiler I had was FST for DOS, and (IIRC) it wasn't really suitable for embedded use.

Regards,

-=Dave

... snip ...

In many (but not all) cases those things are best handled with sets. In my systems I did define an additional function mask(integer, integer) : integer; for just that purpose. Proper definition of subranges and multiplications could combine bit fields perfectly well. The compiler converted most multiplications by constants into shifts.

...snip ...

That no longer applies to extended (ISO10206) Pascal, and was avoided by non-standardized extensions in most systems back when. Mine handled separate compilation by leaving out the main program block, but not the final period. Global data was handled by an include file, since only the outer block did any space assignment for globals. Kludgy, but it worked.

That reminded me of a saying I once heard:

Pascal makes you say "please", while C makes you say "I'm sorry".

-Robert Scott Ypsilanti, Michigan (Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)

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.

Mike

Sounds interesting. Can you provide references to such evidence, obtained under the stated conditions?

I'd also be interested in documentation of the ranking of languages "as determined by safety-critical industry concensus."

It's well-known that it's easier to ask forgiveness than permission.

Regards,

-=Dave