Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!tut.cis.ohio-state.edu!purdue!haven!udel!princeton!phoenix!gauss!markv
From: markv@gauss.Princeton.EDU (Mark VandeWettering)
Newsgroups: comp.sys.sgi
Subject: Re: IRIX 3.2 C compiler bug (Mark Gets Pie in the Face)
Message-ID: <13600@phoenix.Princeton.EDU>
Date: 5 Feb 90 20:03:01 GMT
References: <90Feb5.000622est.4918@neat.cs.toronto.edu> <13583@phoenix.Princeton.EDU> <12999@cgl.ucsf.EDU>
Sender: news@phoenix.Princeton.EDU
Reply-To: markv@gauss.Princeton.EDU (Mark VandeWettering)
Organization: Princeton University
Lines: 26

In article <12999@cgl.ucsf.EDU> conrad@cgl.ucsf.edu (Conrad Huang) writes:
>Say what!?  In K&R, Appendix A, page 189, Section 7.6,
>
>	"The operators < (less than), > (greater than), <= (less than or
>	equal to) and >= (greater than or equal to) all yield 0 if the
>	spricified relation is false, and 1 if it is true"

Gadzooks.  I went back and looked this up, and you were right.  I had 
always operated on the assumption that the only thing you knew about
TRUE was that it wasn't zero.  Oh well, pie in my face number one.

>In the first place, the program ought to print 0, since 1.0 == 2.0 is *false*.
>In the second place, even if they were equal, it should print 1.000000.

Actually, if we wanna get really technical about it, this program shouldn't
work at all, because you passed a double to the printf, when in fact it 
wants a float argument.  This usually works out, but I have had it fail 
on various machines (particularly mips based ones) in very odd ways, so
one should be careful.

But ignoring that, you are of course correct.  It should return 0.0000
and doesn't.  Pie in the face #2 for me.

That's what I get for posting late at night.

Mark