From owner-freebsd-hackers Mon Feb 23 11:47:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA26793 for freebsd-hackers-outgoing; Mon, 23 Feb 1998 11:47:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from server4.mpcbbs.com.br (server4.mpc.com.br [200.246.0.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA26262 for ; Mon, 23 Feb 1998 11:46:21 -0800 (PST) (envelope-from capriotti@geocities.com) Received: from hot_nt (node73.mpc.com.br [200.246.0.73]) by server4.mpcbbs.com.br (8.8.6/8.8.6) with SMTP id RAA14017 for ; Mon, 23 Feb 1998 17:46:13 -0200 (EDT) Message-Id: <3.0.32.19980223174448.009a1dc0@pop.mpc.com.br> X-Sender: capriotti@pop.mpc.com.br X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 23 Feb 1998 17:44:53 -0300 To: hackers@FreeBSD.ORG From: Capriotti Subject: Re: My Compiler Confusion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, if the code is ok, so the compilers are crooekd. Is there anything to do with the FBSD FP support / I remember there is a note somewhere saying that GENERIC kernel support to FP (made by SW) was not that good, and should be replaced (compile the lernel w/ HW FP support enabled) if FP was REALLY an issue. But I can't see why it would be causing problems with compilation ! Just guessing. At 06:51 PM 2/23/98 +0000, you wrote: >>What are they(*) _really_ trying to do with that cast-cast-compare code? >>((*) I am not the original author of this Work of Art...) > >I reckon they're trying to avoid using an FP constant if the integer is >truly equivalent; might be cheaper on some targets. > >>Given that the constant really _doesn't_ fit in the integer, I think >>the intent of this code is to essentially determine that fact and >>then cause the compiler to do something else (more correct), than >>silently substitute 0 in the generated code, as it does on the Solaris >>box using the bbc or gcc. > >Well, according to the only reference I have to hand, "When a value of >floating type is converted to integral type, the fractional part is >discarded; if the resulting value cannot be represented in the integral >type, the behaviour is undefined." (K&R II A6.3). So the Solaris behaviour >is just fine. > >>How _should_ this cast-cast-compare test really be written to be >>more correct? As a range test? Invert the test by taking max-int >>and placing it in a float for the compare, which must be done >>using a floating compare? > >If I'm right about what they're trying to do, the code is probably OK. > > >-- >Bob Bishop (0118) 977 4017 international code +44 118 >rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message