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."