Hi guys,

Over the last few years, I have written hundreds of thousands of lines of object pascal code that compiles successfully using the FPC and Delphi. To date, I have not encountered any problems with the code generated by the FP Linux compiler. I don't have much experience with FPC within the MS Windows environment as my current interest lies in developing console Linux apps.

Like most developers, I strive to write code that is as bug free as possible and at the end of each day, I'm left with a feeling of great satisfaction and achievment.

IMO and experience, the code generated by the FPC is as resilient as the operating system it runs on.

My question is directed to the FPC team and in particular, to those involved in the development of the compiler and more specific, the Linux compiler. (I would expect that Florian would have a say here).

In your opinion, how would you rate the suitability of the FPC generated code for use in an environment where there is near zero tolorance to failure? Consider the question assuming that the ideal condition where that the source code is as close to being perfect as possible, (and I'm not suggesting that this perfect code would be written by me. I'm not that good).

Where am I going with this question you might ask? Well, what is the difference with say, the code generated by an ADA95 compiler and that generated by the FPC. Perhaps someone out there might know. What determines the robustness of the generated code? Could the FPC be rated by some authority as being able to generate code of some world defined standard?

I know that if I were to manufacture a device or appliance that was controlled by FPC code and the device, say a home alarm system, functioned as designed and as specified, then the fact that the device is controlled by code generated by the FPC would be irrelevant. However, if the device were designed to control the laser beam that reshapes a human cornea (eye), then the compiler and operating system is of relevance. (The possibility of someone using MS Windows CE and Micro .NET comes to mind).

In conclusion, perhaps somebody has already had similar thoughs with regards to the above question(s) and has some answers. Would be cool to have the FPC team's sincere thoughs on the above.

Keep up the good work guys and thanks for a superb compiler (and RTL - of course).

Regards,
Nino

In your opinion, how would you rate the suitability of the FPC generated code for use in an environment where there is near zero tolorance to failure?

Unsuitable. There are no systematic unit tests for most parts of the compiler, nor many integration tests.

Jonas

Hi Nino:

I am using FPC since 2000-2001. I use it for data aquisition and temperature control. Console programs compiled with FPC 1.x work for days, even weeks. In the "Laboratorio de Física del Sólido, Tucumán - Argentina" (Solid state physics laboratory) we have used programs compiled with FPC to grow YBACuO superconductor crystals. This process take weeks.
This heat treatment is the only "mission critical application" that I know well, and FPC works reliably, even for weeks, on linux machines.

Gustavo

ps:excuse my english

2009/5/8 :

Wow!, is good to know I'm not the only Argentinian using FPC.

Leonardo M. Ramé
http://leonardorame.blogspot.com

Some of my fpc programs run for months on linux clusters and some multi threaded daemons on OS X til reboot. So far: No long time crashes or mem leaks.

But I second Jonas mail: Before you run an fpc program in a zero-tolerance environment, you have to test a lot of things, because a lot of code was not written with zero-tolerance in mind.

Mattias

Mattias Gaertner :

But I second Jonas mail: Before you run an fpc program in a zero-tolerance environment, you have to test a lot of things, because a lot of code was not written with zero-tolerance in mind.

Testing simply isn't enough. As we all should know, testing only proofs the existance of bugs, not their absence.

So, no, I wouldn't recommend FPC for mission or safety-critical applications. After all, you need a lot more than just a compiler to have some confidence about the running application.

Depending on your personal definition of "zero-tolerance", you even may need _proof_ of correctness at object code level. At that point, the compiler doesn't matter anymore. And, well... even Ada compilers have bugs, although the general confidence about the code generator might be a bit higher if they successfully passed the ACATS. ;)

Vinzent.

I could add my experience:
I have made a system for controling the internet connection for a network of nearly 100 computers.The system checks passwords, set up permissions, takes care of the full log of internet traffic, regularly extracting informations from the log files (which is a huge amount of data). The system is a daimon program, compiled with FreePascal, running on an Ubuntu Linux OS. The computer with this system has now been running for more that a year without interruption, without reboot, and without any sign of any problem.

But then, in case of zero-tolerance, if you trust the compiler, what about the OS? and, worst, what about your program? I wouldn't trust the reliability of anything before the full system has been tested under working conditions.

Hans Mårtensson

Von: "Hans Mårtensson" :

But then, in case of zero-tolerance, if you trust the compiler, what about the OS? and, worst, what about your program?

And what about the CPU? ;)

I wouldn't trust the reliability of anything before the full system has been tested under working conditions.

What about stress conditions? Programs usually tend to fail under conditions you didn't think of. (One reason being that the conditions you /did/ think of have been put to the test. Usually.). But working conditions seldom fall into that category.

Actually, you should answer one simple question for yourself: If your life really depended on the system, would you still trust it?

Vinzent.

Actually this is a very difficult question to answer properly . As a very productive program writer since ( approximately ) 1973 I can say that the problem has a significant number of parameters to consider such as :

- Specifications about software
- Algorithm design of the software by the programmer
- Used language constructs of selected compiler
- Compiler itself
- Libraries used by the compiler
- Operating system
- Testing the developed software
- Hardware running the software
- and others ...

There is a definition that reliability of a system can not be greater than its reliability of weakest
component ( having minimum reliability ) .

All of the above components and other unspecified components will comprise a system as a whole .

When considering FPC :

- There are internal error points generated during run time triggered by the user program .
It is necessary to write programs which avoid those points ( if possible ) .

For an error free program , FPC generates very good code with the reminder that all of the
software may contain bugs and an exhaustive test of FPC to generate a fault-tolerant compiler
may require combinatorial steps which is beyond the existing capabilities .

In that respect ADA could not be adopted widely because its compilation depended on C compilers which they ( C compilers ) are not conforming to ADA specifications .

- FPC is NOT compliant to Delphi ( a very obvious feature , at least FPC is for cross-platform whereas Delphi is only for Windows platform ) . A program compiled and working perfectly in one of them is not a guarantee that it will work perfectly when compiled by the other .

- FPC ( and Lazarus are ) is using external libraries such as GTK and/or QT which those are beyond of FPC team control . Bugs in FPC ( and Lazarus ) are corrected promptly by generating a very good work by the FPC teams , but other libraries have their own development teams and work schedules .

Since May 2008 I am trying to learn FPC as much as possible . Nearly all of my problems are caused by the libraries used , NOT by the FPC itself ( except a few ) .

- It is necessary to write programs to handle run-time exceptions properly . Compiler can not do anything much about that . A ( try ... except raise exception ) structure may have disastrous effects on outcome of a program when it is run when a life-critical system is controlled by such a program . The program should be designed properly to handle such situations without causing disasters . For example , in an airplane fall-down many years before ( approximately 110 deaths ) it has
been found that in the automatic pilot software an error situation used a STOP statement . During landing it caused release of control of the airplane by the automatic pilot ( then the related company had discontinued the software automatic pilot and reverted to mechanical control ) .

These are my ( partial ) opinions about the above question .

Thank you very much .

Mehmet Erol Sanliturk

"Vinzent Höfler" wrote

Actually, you should answer one simple question for yourself: If your life really depended on the system, would you still trust it?

In that case we should all be very worried. Many critical systems out there run on Windows - we as technical people know that Windows is not the most stable platform out there. :-)

The basic question is: Can we fully trust computers? NO - but we have to unfortunately. Computers are built up of many components. We have no idea how well those components have been tested and simply have to trust that sufficient testing has been applied. The software compiler is just one of those many components.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Mehmet Erol Sanliturk wrote

For example , in an airplane  fall-down  many years before ( approximately 110 deaths ) it has been found that in the automatic pilot software an error situation used a STOP statement . During landing it caused release of control of the airplane

This happens more often than you think. I watched a few days ago a program about a SAAB military aircraft test pilot that survived 3 airplane crashes. Each crash destroying a $24mil plane. The first two crashes where caused by the on-board software failing - software crashed. They then did some serious software bug fixing and were confident that the software defects are solved. The 3rd crash was caused by the now nervous pilot, over compensating for what the software wanted to do. This overloaded the software with inputs it simply couldn't handle fast enough and the software simply started dropping instructions to try and keep up. Needless to say, that plane crashed as well.

After that the pilot stopped being a test pilot for that specific model aircraft, but SAAB did eventually manage to fix all the software bugs. Quite an expensive debugging session.

Moral of the story? Test, test and TEST! And when in doubt, test some more!

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Mehmet Erol Sanliturk wrote

For example , in an airplane  fall-down  many years before ( approximately 110 deaths ) it has been found that in the automatic pilot software an error situation used a STOP statement . During landing it caused release of control of the airplane

This happens more often than you think. I watched a few days ago a program about a SAAB military aircraft test pilot that survived 3 airplane crashes. Each crash destroying a $24mil plane. The first two crashes where caused by the on-board software failing - software crashed. They then did some serious software bug fixing and were confident that the software defects are solved. The 3rd crash was caused by the now nervous pilot, over compensating for what the software wanted to do. This overloaded the software with inputs it simply couldn't handle fast enough and the software simply started dropping instructions to try and keep up. Needless to say, that plane crashed as well.

After that the pilot stopped being a test pilot for that specific model aircraft, but SAAB did eventually manage to fix all the software bugs. Quite an expensive debugging session.

Moral of the story? Test, test and TEST! And when in doubt, test some more!

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Hi Graeme

You have a point.

About two months ago, I had to visit the dentist because one of my filings was playing up. The diagnosis was that an old silver filing was leaking and needed to be replaced. Becase of all the hype about mercury poisoning caused by silver filings (which from my knowledge silver filings contains basically silver nitrate), the dentist suggested using an inlay which is made of some composite plastic etc.

I agreed and a mobile PC on wheels was rolled in by his nurse. I noticed the familiar green start button on the bottom left corner of the screen and asked what version of Windows XP this box was running. The dentist's reply was that this was a special version of windows specifically designed to run medical related critical software. Not being an offensive character, I gave him the benefit of the doubt. While he was attempting to start the 'tooth profiling' program, he clicked on a tab on the taskbar and up popped MS Solitare! Obviously this medical box was trying to pay for itself in more ways than its intended use.

To cut a long story short, during the three dimensional scan of my tooth, the Windows box blue screened. After a reboot, it worked fine until the tooth inlay cutting process, where the program controls a milling machine. The milling process takes close to half an hour to complete, and half way through the milling process, yes you guessed it, the controlling program crashed in Windows. I remarked that the inlay would now be useless, but the dentist's reply was "no, it's okay, it happens quite often. Just can't restart the program or the milling will stop".

When I peeked at the back of the Windows box, I was quite surprised to find a Siemens logo!

Also, a few weeks later, my inlayed tooth required a root treatment.

IMO, A good programmer using FPC and Linux will produce a more stable product than the same programmer using anything (MSVS, Delphi, DotNet, whatever) and running in Windows. By the way, I have nothing against MS or Windows. I think that MS has done a pretty good job since NT4, mostly thanks to Dave Cutler and his team (ex Digital VMS OS architect - is that why NT was more stable than 95, cause it's based on Unix?). Apart from poorly written software, poorly written device driver are the major cause of Windows OS crashes. Of course viruses and trojans etc don't help either.

Anyway, In my opinion and experience, I think that Free Pascal is suitable for mission critical work and yes the system as a whole must comply. The OS, the hardware the software. Redundancy must also be factured in. Most embedded device have a hardware watchdog that will reset the device when required.

Signing off,
Nino

//-------------------------------------------------------------------------

The dentist's reply was that this was a special version of windows specifically designed to run medical related critical software. Not being an offensive character, I gave him the benefit of the doubt. While he was attempting to start the 'tooth profiling'

Probably Windows XP Embedded. We use it a lot in the POS industry.

http://www.microsoft.com/windowsembedded/en-us/products/wexpe/default.mspx

El Sat, 9 May 2009 10:08:50 +0200
Graeme Geldenhuys escribió:

And many of those are written in visual basic: many years ago I saw a job ad on a newspaper requesting visual basic programmers for electromedical machines. I *am* worried.
Not too long ago I saw on digg a photo of a scada controlling a nuclear plant. The scada was siemens' wincc[*]. Regardless of the fact that the error message was just complaining about the license, and a scada isn't actually controlling the plant, I am *very* worried.

[*]a gigantic mess with a bazillon programs and dlls that nobody on earth could possibly know how they fit together, and with the final program badly scattered among so many different pieces you can't never be sure of what is doing.

See the follow up of this thread in fpc-other

Giuliano

ha scritto: