Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!cmcl2!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: net.lang.c,net.unix
Subject: Re: SIGFPE C quiz answer
Message-ID: <173@brl-smoke.ARPA>
Date: Mon, 21-Apr-86 10:29:17 EST
Article-I.D.: brl-smok.173
Posted: Mon Apr 21 10:29:17 1986
Date-Received: Thu, 24-Apr-86 07:20:10 EST
References: <222@rtech.UUCP>
Distribution: net
Organization: Ballistic Research Lab (BRL)
Lines: 20
Xref: watmath net.lang.c:8712 net.unix:7692

> ...  Since "f" is not initialized, it may contain an illegal floating
> point number.  When the conversion is attempted, the system may very
> well say, "acckkk pffft!, I don't grok that value!!!," and send a
> signal.
> 
> I have seen this provoked on VAXen and on machines with National's 32xxx
> series floating fpoint co-processor.  Doug Gwyn suggests it can happen
> easily on PDP-11s as well.  You should consider it a bug everywhere.

Yes, doing anything with uninitialized data other than storing
a valid value in it should be considered an error.

However, the PDP-11 problem is more subtle.  Floating-point auto
variable reference can cause a trap to grow the stack, but with
some models of FP11 there is no way to recover from the fault.
The simplest fix is to have the compiler "touch" the lowest
stack location via TST (SP) immediately after allocating space
for the autos, so that the stack grows on a non-floating-point
reference.  Our PDP-11 C compiler does this under the same
circumstances that a reference to "fltused" is generated.