On Tuesday, 18 February 2014 at 23:05:21 UTC, Walter Bright wrote:
http://cacm.acm.org/magazines/2014/2/171689-mars-code/fulltext
Some interesting tidbits:
"We later revised it to require that the flight software as a
whole, and each module within it, had to reach a minimal
assertion density of 2%. There is compelling evidence that
higher assertion densities correlate with lower residual defect
densities."
This has been my experience with asserts, too.
"A failing assertion is now tied in with the fault-protection
system and by default places the spacecraft into a predefined
safe state where the cause of the failure can be diagnosed
carefully before normal operation is resumed."
Nice to see confirmation of that.
"Running the same landing software on two CPUs in parallel
offers little protection against software defects. Two
different versions of the entry-descent-and-landing code were
therefore developed, with the version running on the backup CPU
a simplified version of the primary version running on the main
CPU. In the case where the main CPU would have unexpectedly
failed during the landing sequence, the backup CPU was
programmed to take control and continue the sequence following
the simplified procedure."
An example of using dual systems for reliability.
Having read Code Complete when I was at the university, coupled
with Ada and Eiffel experience, allowed me to live better with C
by
- compiling with all warnings enabled as errors
- making judicious use of assert as poor man's contract system
- running the code regularly with static analyzers
Regarding the last point, I read somewhere that lint was actually
supposed to be part of C toolchain, but when most people tried to
port C to home computers it was highly overlooked, hence the
situation we got into with C.
--
Paulo
