Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site watdaisy.UUCP Path: utzoo!watmath!watdaisy!ndiamond From: ndiamond@watdaisy.UUCP (Norman Diamond) Newsgroups: net.lang Subject: Re: Runtime trapping of program bugs Message-ID: <6854@watdaisy.UUCP> Date: Sun, 13-Jan-85 15:08:09 EST Article-I.D.: watdaisy.6854 Posted: Sun Jan 13 15:08:09 1985 Date-Received: Mon, 14-Jan-85 01:57:52 EST References: <5143@rochester.UUCP> <19@decvax.UUCP> <481@ecsvax.UUCP> Organization: U of Waterloo, Ontario Lines: 27 > The current WATFIV compiler for the IBM 360 compatible computers > still initializes all variables to an invalid floating point constant > (creates bad memory parity if *MY* memory serves me right). Nice > feature for debugging FORTRAN programs. > Ted H. Emigh Genetics and Statistics, North Carolina State U, Raleigh NC Nope; Watfiv generates CODE to check whether a variable contains the magic value (hex 80 in every byte, the semantic "value" depending on the datatype). A compiler option can be used to turn off generation of error-checking code, for that error only. This option is rarely used. The inverse option (to perform such checking) is rarely available in real-world compilers. It is unfortunate that a lot of people still think that it would be more expensive to use such checks in the debugging stages of programs than it is to pay programmers to find the same bugs. The Diagnose machine instruction (the real one) might generate bad parity among its tests, but a problem program like Watfiv would not be able to take advantage of it. -- Norman Diamond UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdaisy!ndiamond CSNET: ndiamond%watdaisy@waterloo.csnet ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa "Opinions are those of the keyboard, and do not reflect on me or higher-ups."