On Mon, Apr 4, 2011 at 12:13 PM, David Brown <david@xxxxxxxxxxxxxxx> wrote: >> ... and then, on top of that, you duplicate your variables into >> different parts of RAM and do a bit comparison before you use them >> for some purpose, just in case you have the chance to catch something >> - and perform a safety reaction - in time to avert disaster. How much does it help to protect some variables, isn't it needed to also protect stack, heap and so on? If you do not trust the memory, how can you trust the code executed from memory? Do you have integrity checks running? I remember a case where a background flash memory integrity check caused crashs in rare race conditions due to some resource conflict... > /All/ error detection or correction systems add more to the > overall system, so you have to weigh the potential benefits > against the potential risks. Especially when also considering long-term code maintenance, yes. [ECC hardware: simple and clean] > But duplicating some variables and checking them at certain > points sounds very ad hoc to me, and the it is difficult to be > sure you are doing more good than harm. When not trusting RAM, ECC seems the natural solution for that. If not trusting CPU etc, variable duplication seems not to fully solve the issues, I guess. Is variable duplication reasonable safer than simply executing the complete functional unit/code twice in different memory places? Is something like this used in some projects? Maybe with optimized and non-optimized code (to have different memory layout / register usage)? > See point 9 in > <http://www.jokesunlimited.com/jokes/if_microsoft_made_cars.html> :-) :) OT: You think you are joking, but modern ESC (http://en.wikipedia.org/wiki/Electronic_stability_control( sometimes comes close to this! In some conditions you have to turn it off but on some cars you have to press some button (often not placed at a location where it can be found quickly and blindly) and you may even have to hold it for one second before ESC turns off. Probably for safety. To avoid to turn it off accidentally. But when drifting in a roundabout, you may not have 1000ms to play with some funny buttons... "Are you sure you want to turn off ESC to avoid your car jumping in the roundabout?" lol > moment, though I'll probably get one before long), but one I > remember as standing out was the rule for a style "if (1 == x) > ...". It recommends you think backwards, read backwards and > write backwards, to avoid a design flaw in the C language that > is easily checked by the compiler. The dark side are they. Or a matter of habit it is. For young Jedi with 800 years old compiler, good this practice is: miss them do not! SCNR :) > Still, I have no statistics to back up my opinions, and I fully > appreciate the value of standards like MISRA even if I don't > like them! Yes, a first positive effect already is that people consider more in depth what they do, which already improves safety (and security). >>> Compile-time warnings and error checking are steadily improving >>> with each new version of gcc, but I'd say that more work here would >>> have greater benefits for code safety than automatic variable >>> duplication. >> >> I concur - and this is why I suggest that anyone looking at a >> safety-critical application, wanting to do variable duplication for >> protective reasons, implement it themselves. I guess it is impossible to know how many failures were caused due to memory bit flips and how many caused by programming bugs (and how severe they were). oki, Steffen
