Compiler bug or gray area in C?

Chris Torek chris at mimsy.umd.edu
Thu Nov 29 19:46:17 AEST 1990


In article <1990Nov28.220233.2630 at ingres.Ingres.COM> daveb at ingres.com writes:
>Given this simplification:
>	
>	extern	double D, foo();
>
>	foo( i )
>	int i;
>	{

Type error, foo returns double and int.  Because of the next problem, I
am almost sure you meant `bar(i)':

>		double	x;
>		int	changes = 0;
>		do {
>	
>			x = foo( i );

Infinite recursion: to compute foo(i) we must first compute foo(i) before
doing anything else.

>			if( x < D )
>			{
>				changed++;
>				D = x;
>			}
>	
>		} while( !changed );	
>	}

Repaired example:

	fn() {
		double x, eval(void);
		extern double D;
		extern void nop(void);

		for (D = x = eval();;) {
			nop();	/* does not change D */
			if (x < D)
				D = x;
			else
				break;
		}
	}

>is it reasonable for this to not terminate?

I think so; I think that the reason you give here is not (quite) outlawed.

>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.  
>
>Yes, floating point in C is peculiar, but is it _this_ peculiar?

(Floating point in C is no more peculiar than floating point anywhere
else.  Or, more succinctly, floating point is peculiar everwhere.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris



More information about the Comp.lang.c mailing list