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: 103376,885dab3998d28a4 X-Google-Attributes: gid103376,public X-Google-Thread: 101deb,885dab3998d28a4 X-Google-Attributes: gid101deb,public X-Google-Thread: 107079,eca28648989efca9 X-Google-Attributes: gid107079,public X-Google-Thread: f74ae,eca28648989efca9 X-Google-Attributes: gidf74ae,public From: "Wayne L. Beavers" Subject: Re: Ariane 5 failure Date: 1996/09/30 Message-ID: <52p49m$kug@beyond-software.com>#1/1 X-Deja-AN: 186279091 nntp-news-admin: newsadmin@beyond-software.com distribution: inet references: <1780FB1E3.KUNNE@frcpn11.in2p3.fr> <324F1157.625C@dynamite.com.au> content-type: text/plain; charset=us-ascii organization: Beyond Software mime-version: 1.0 newsgroups: sci.astro,sci.math.num-analysis,comp.lang.pl1,comp.lang.ada x-mailer: Mozilla 2.02 (Win95; I) Date: 1996-09-30T00:00:00+00:00 List-Id: 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. 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.