[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