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