daveb@rtech.UUCP (Dave Brower) (04/20/86)
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
gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/21/86)
> ... 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.