[Safety-related]: Re: Which tools or software are most critical to the integrity o



Date view Thread view Subject view Author view

Jonathan Moffett (jdm(at)cs.york.ac.uk)
Mon, 26 Oct 1998 13:02:48 +0000


I am forwarding this to the list as it was filtered out because it did not contain "safety" in the subject line or message. Jonathan Moffett Safety-critical mailing list moderator >Sender: ladkin(at)rvs.uni-bielefeld.de >Date: Mon, 26 Oct 1998 11:15:40 +0100 >From: "Peter B. Ladkin" <ladkin(at)rvs.uni-bielefeld.de> >To: hise-safety-critical(at)cs.york.ac.uk >Subject: Re: Which tools or software are most critical to the integrity o >References: <swordfish.909263445(at)cs.york.ac.uk> >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >> [PBL] Now, if there are no errors in your program, the compiler has no >> errors, and there aren't any errors in the design of the machine code, >> you would imagine that concatenating error-free operations from an >> error-free source should yield an error-free result. But that is not >> necessarily the case, under this interpretation of (at)error-free >> compilation'. > >> [PGB] Not really, you have missed out a crucial part of the system >> - the hardware. >> If you don't have enough memory >> or there is something else wrong with the >> hardware configuration, (e.g.input-output >> is incorrectly connected) then the program >> can still fail (potentially disastrously). > >Peter, thank you for corroborating my point. You're right that (at)design >of the machine code' isn't a phrase that would normally include miswired >machinery, but I wonder whether it should include such hardware >constraints as memory limitations. > >One way of sorting this out is to introduce more levels: >1. source code to (at)abstract' object code; >2. (at)abstract' object code to (at)concrete' object code (namely, (at)machine >code' for the actual machine, rather than for some abstraction of it). >Then your compiler would be the part that did step 1, and some other >translator would do step 2, thus saving Darren and Brian's implicit >suggestion that (at)compiler bugs' are those problems which occur in >step 1. Arguing against this is that nobody builds any tool to do >step 2. In fact, you seem to be arguing, strangely, that it should >remain implicit: > >> [PGB] The program "proof" is in an assumed context >> (sufficient memory, correct connenctions). >> If the assumptions about the environment are invalid, >> it invalidates the whole argument. > >So instead of making the constraints explicit, and having >compositionality of error-freeness amongst the various components >of a software development, you'd rather they continue to be implicit, >and that we give up on compositionality? I find that a very odd >suggestion. > >> No need to blame the compiler. > >That depends whether you expect a compiler to produce error-free >object code from error-free source, without implicit assumptions. > >PBL > >---------------------- --------------------- >Peter Ladkin, Professor fuer Rechnernetze und Verteilte Systeme >ladkin(at)rvs.uni-bielefeld.de http://www.rvs.uni-bielefeld.de >Snailmail: Universitaet Bielefeld, Technische Fakultaet, > Postfach 10 01 31, D-33501 Bielefeld, Germany >Tel: +49 (0)521 106-5326/5325/2952, Fax (new): +49 (0)521 106-6440 >---------------------- --------------------- >


Date view Thread view Subject view Author view