Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!udel!princeton!phoenix!gauss!markv
From: markv@gauss.Princeton.EDU (Mark VandeWettering)
Newsgroups: comp.sys.sgi
Subject: Re: IRIX 3.2 C compiler bug
Message-ID: <13583@phoenix.Princeton.EDU>
Date: 5 Feb 90 14:37:07 GMT
References: <90Feb5.000622est.4918@neat.cs.toronto.edu>
Sender: news@phoenix.Princeton.EDU
Reply-To: markv@gauss.Princeton.EDU (Mark VandeWettering)
Organization: Princeton University
Lines: 34

In article <90Feb5.000622est.4918@neat.cs.toronto.edu> ken@cs.toronto.edu (Ken Lalonde) writes:
>On a 4D/240S running 3.2:

>	% cat t.c
>	main()
>	{
>		double a,b,c;
>
>		b = 1.0;
>		c = 2.0;
>		a = b==c;
>		printf("a=%f\n",a);
>	}
>	% cc t.c
>	% ./a.out
>	a=2147469288.000000

Just what did you expect this to return?  Unless I am mistaken, ANSI C 
still doesn't any distinction about what number is returned, only that 
it is NOT zero, which is certainly the case for your code here.  It is probably
also true that comparison of floating point numbers is an inherently dicey
proposition.  

It is also probably bad practice to use a "double" to receive the results
of a comparison, the result is usually concieved as an integer quantity.  The 
implicit conversion in the statement above is a little strange and misleading.

If I have a complaint, it is that compilers tend not to warn someone 
of such inherently unportable code.  

I guess the maxim would be "A correct compiler shouldn't have to compile
incorrect programs".  

Mark