Actually it's printf.. (was Re: Another C compiler bug)

[John Martin]

In article <1990Nov1.153433.4006 at cimage.com> brian at dgsi.UUCP (Brian Kelley) writes:
>In article <11565 at sybase.sybase.com> mcfong at mercury.sybase.com () writes:
>>[...]
>>Looks like yet another compiler bug which MIPS has fixed but DEC and
>>SGI have not yet picked up.
>>[...]
>I think the main problem is ULTRIX 4.0 is using version 2.00 of the MIPS
>C compiler.

No, actually I suspect that the real culprit is "printf" not rounding
properly (though I confess I haven't checked the binary form for the
7e-7 floating-point value to completely absolve the compiler).

To test my hypothesis, here's a little binary search program that
determines the value below which all floating-point values will be
printf'ed as "0.000000":

---------------------------------------------------
#define TRACE(x)
/*#define TRACE(x)	printf("mid = [e]%e: [f]%f\n", x, x)*/
#define STREQ(a,b)	(strcmp(a,b) == 0)
char	zstr[] = "0.000000";	/* watch for all zeroes */

int
main()
{
float	lo=0.0, hi=1.0, mid;
char	buf[10];

	for (;;) {
		mid = 0.5 * (hi+lo);
		TRACE(mid);
		if (mid == hi || mid == lo) break;
		sprintf(buf, "%f", mid);
		if (STREQ(buf, zstr))
			lo = mid;
		else
			hi = mid;
	}
	printf("hi = %e\n", hi);
	printf("lo = %e\n", lo);
	return (0);
}
---------------------------------------------------

On my DECstation 3100 running Ultrix 4.0, this produces the output:
     mips
     ----
hi = 9.500000e-07
lo = 9.500000e-07

I also tried it on different, admittedly non-mips, systems:

     68k sun              sparc                vax/vms
     -------              -----                -------
hi = 5.000001e-07    hi = 5.000001e-07    hi = 5.000001e-07
lo = 5.000000e-07    lo = 5.000000e-07    lo = 5.000000e-07

As you can see, the "printf" in Ultrix 4.0 simply seems to be choosing
the wrong place to round up.  I really doubt that the mips compiler
could be goofing when initializing 'lo' to 0.0, 'hi' to 1.0, or the 0.5
constant in the 'mid' calculation, or that the fundamental floating
point calculations are seriously perturbed.  It looks like an output
formatting problem to me.
--
John Martin, Applied Dynamics International, Ann Arbor, MI, (313)973-1300
jcm at adi.com || jcm%amara.uucp at mailgw.cc.umich.edu || ...uunet!sharkey!amara!jcm
"How many times over the past six months did you, or people working for you,
 write some program fragment for table searching?" -- Bertrand Meyer