On Sun, 12 Feb 2006 13:46:05 -0500, John Denker said: > That is a remarkably unprofessional suggestion. I hope the people > who write software for autopilots, pacemakers, antilock brakes, > etc. do not follow this suggestion.
Thus my remark about a independend failsafe system. I strongly hope that for life critical systems nobody even things about throwing in a bunch of general purpose libraries and declares the task as done. Fortunately these systems have resource constraints so that such a solution won't come to mind anyway. > First of all, "impossible" is the wrong word. If the condition s,impossible,not foreseen/tested/coded by the developer, > previous tick's tasks are finished. What do you do, exit? If Yes. And one of the concurrent running system will take over. In 1969 this system used to be Armstrong, though. > There are other stories like this, including funny (?) stories of > what happens if exceptions are not handled so well. Terminating a process is a well handled exception. Think of hardware failure; continue while knowing that tehre is something really weird going on?? > More generally: library routines should never exit. They almost If you are thinking of exit please mentally translate this to assert. Still believing one should never call assert(0) in a library? > Nitpickers note: I can imagine a situation where the stack is so > messed up that you can't thrown an exception or even return from Die as soon as you can; kill (getpid(),SIGKILL) might even be justified in such a situation. Try to make an attackers life as hard as possible. Yes, for life critical systems an attack scenario might be different to judge and thus the design needs to be different. Obviously I agree with Ben that that there is no way to know the current state if something went wrong in unexpected ways. Shalom-Salam, Werner --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]