Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!fozzie!stanley
From: stanley@phoenix.com (John Stanley)
Newsgroups: comp.lang.c
Subject: Re: Compiler bug or gray area in C?
Message-ID: <9uHFT1w163w@phoenix.com>
Date: 30 Nov 90 02:53:07 GMT
References: <1990Nov28.220233.2630@ingres.Ingres.COM>
Organization: One Man Brand
Lines: 54


daveb@ingres.com (When a problem comes along . . . you must whip it) writes:

> Given this simplification:
> 	
> 	extern	double D, foo();
> 	
> 	foo( i )
> 	int i;
> 	{
> 		double	x;
> 		int	changes = 0;
> 		do {
> 	
> 			x = foo( i );
> 	
> 			if( x < D )
> 			{
> 				changed++;
> 				D = x;
> 			}
> 	
> 		} while( !changed );	
> 	}
> 
> is it reasonable for this to not terminate?
> 
   Hmm. First thing foo does is invoke foo again. I would say this will
not terminate until the stack overflows. Is that reasonable?

   If this problem were introduced by the simplification, then there is
still the problem that foo never returns a value. Whatever happens to
show up in x will be whatever was left in the registers. Is that going to
be less than D? Who knows?

> We see a number of compilers that keep x in a register with extended
> precision, so that it has bits that are not in the global D.  Thus, the
> comparison (x < D) fails, even after D is assigned the value of x.  
> 
   Ah. Floating comparisons. This is a problem that was well known (at
least to me) in the Sun workstations (for one example). The 68881 FPU has
an 80 bit register.  This will rarely equal anything that has passed
through the 64 bit double. Sun had a flag on the compiler to force
floating ops to use only 64 bits from the FPU. I don't remember what it
is.

> Yes, floating point in C is peculiar, but is it _this_ peculiar?

   This is not C, it is hardware. Yes, that peculiar.


<> "If winning is not important, then why keep score?" -- Turtle Head
<> "Eaten any good books lately?" -- Q
<> "Sanity check!" "Sorry, we can't accept it, it's from out of state." - me