From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 107079,eca28648989efca9 X-Google-Attributes: gid107079,public X-Google-Thread: f74ae,eca28648989efca9 X-Google-Attributes: gidf74ae,public X-Google-Thread: 103376,885dab3998d28a4 X-Google-Attributes: gid103376,public X-Google-Thread: 101deb,885dab3998d28a4 X-Google-Attributes: gid101deb,public From: Ken Garlington Subject: Re: Ariane 5 failure Date: 1996/10/01 Message-ID: <3251322B.1076@lmtas.lmco.com>#1/1 X-Deja-AN: 186529818 references: <1780FB1E3.KUNNE@frcpn11.in2p3.fr> <324F1157.625C@dynamite.com.au> <52p49m$kug@beyond-software.com> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Tactical Aircraft Systems mime-version: 1.0 newsgroups: sci.astro,sci.math.num-analysis,comp.lang.pl1,comp.lang.ada x-mailer: Mozilla 2.02 (Macintosh; I; 68K) Date: 1996-10-01T00:00:00+00:00 List-Id: Wayne L. Beavers wrote: > > I have been reading this thread awhile and one topic that I have not seen mentioned is protecting the code > area from damage. When I code in PL/I or any other reentrant language I always make sure that the executable > code is executing from read-only storage. There is no way to put the data areas in read-only storage > (obviously) but I can't think of any reason to put the executable code in writeable storage. That's actually a pretty common rule of thumb for safety-critical systems. Unfortunately, read-only memory isn't exactly read-only. For example, hardware errors can cause a random change in the memory. So, it's not a perfect fix. > > I one had to port 8,000 subroutines in PL/I, 24 megabytes of executable code from one system to another. The > single most common error I had to correct was incorrect usage of pointer variables. I caught a lot of them > when ever they attempted to accidently store into the code area. At that point it is trivial to correct the > bug. This technique certainly doesn't catch all pointer failures, but it will catch at least some of them. -- LMTAS - "Our Brand Means Quality"