[SystemSafety] Stupid Software Errors [was: Overflow......]

David MENTRÉ dmentre at linux-france.org
Tue May 5 06:21:14 CEST 2015


Hello,

Le 2015-05-05 00:47, Heath Raftery a écrit :
> Is the implicit assumption that zero run-time errors is better, actually
> sound? Here's a "run time error":
[ ... nice example... ]
> Tada! No run-time errors! Of course, it stops working after a minute.

No, of course. As you perfectly illustrated it, a programmer can "hide" 
a run-time error behind an unwanted behavior. As others said, one must 
take the whole socio-technical context into account and no proponents of 
formal tools said "we have a silver bullet". One should use a formal 
tool AND proper use of the tool, programming language, etc.

> Yes, the tools are great, and not using them would take extraordinary
> justification. But to cry that "integer overflow was fixed 30 years
> ago!" may be missing the point.

I know that Airbus is using such sound static analysis tool on its 
safety critical code. It is part of their process.

That's why I was asking for more information: was the issue identified 
by Boeing (using formal tool or another method) and classified as "won't 
happen" (and probably not documented as such), or was it a real bug 
discovery?

For the latter case, we are several on this list to claim that proper 
tool exists, are perfectly usable on regular desktop machine and should 
be part of the development process.

In the former case, I find it as interesting. How to be sure that such a 
"small" issue, probably identified by some developer in a cubicle, can 
transform into a system requirement "reboot your plane every 120 days"? 
I'm pretty sure several readers of this list would say "it's part of the 
process". But to have such a process really applied in software 
development, not only for avionics safety-critical software, is still an 
open issue for me.

Best regards,
D. Mentré



More information about the systemsafety mailing list