Paul Rubin has already posted some links related to your question.
This is an area that at has to a greater or lessor extent been part of my life for 30+ years.
Here are a few places to start.
A unambiguously defined language. In some was SubC has that. Ada, Pascal and the like are better than C and far from perfect. Implementation defined is convention but has many side effects most of which are unintended.
Focus on goals. The reason for my FDA reference was because they have both goals based on product reliability and safety but also recognize that the tools and the people who use them are far from perfect.
A lot more real research on software engineering and implementation practices.. A simple example of this is tools that walk the generated code applying normal reliability math to the code with any assumption about the reliability of an instruction based on pick one ( 1 , size in bytes, execution cycles) . This will not give you an MTTF that isn't the goal. The goal is to independently evaluate comparative reliabilities. Compare two implementations and it will reasonably accurately predict which will run most reliably. We have created and used such tools and it has had a remarkable positive effect on changes in the way we think about and plan software.
The topic lists for software engineering as opposed to software science is now quite large. Some of the things that are important that I see our better customers using are.
- Application design documents.
- Ram, rom, and execution cycle budgets
- Formal function interface documentation. (Independent component for reliably analysis)
- Coding practice document that support the application goals for a project
That's where I would start
Walter Banks Byte Craft Limited