Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!lll-crg!lll-lcc!unisoft!mtxinu!rtech!daveb
From: daveb@rtech.UUCP (Dave Brower)
Newsgroups: net.lang.c,net.unix
Subject: SIGFPE C quiz answer
Message-ID: <222@rtech.UUCP>
Date: Sun, 20-Apr-86 15:23:51 EST
Article-I.D.: rtech.222
Posted: Sun Apr 20 15:23:51 1986
Date-Received: Wed, 23-Apr-86 13:36:36 EST
Distribution: net
Organization: Relational Technology Inc, Alameda CA
Lines: 39
Xref: watmath net.lang.c:8674 net.unix:7682

Last week, I posted a C quiz, and promised to post the answer.  The
question is, why does the code get a SIGFPE.   Here's the crucial
piece:

> void dynomite( flag, i )
> int flag, i;
> {
> 	float f;
>
> 	if( flag ) i = zerf( &f );
> 	else show( flag, i, f );	/* <-- SIGFPE happens here */
> }

The good news is that almost everyone who mailed me an answer got it
correct.  Congratulations to all of the language lawyers out there!

What is going on is more evil with C's float/double parameter
convention.  The float variable "f" must be converted to a double when
being pushed as an argument to show(), even though show might not use
it.  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.

The moral is,

     **************************************************************
     "Initialize float variables before passing them as arguments."
     **************************************************************

-dB
-- 
Red:   "Whadda ya got that big nose for, granny?"
Wolf:  "Just to HAVE, see!"
{amdahl, sun, mtxinu, cbosgd}!rtech!daveb