Why do most C compilers poxily round towards zero ?

Roberto Shironoshita shirono at ssd.csd.harris.com
Thu Oct 11 01:44:47 AEST 1990


In article <1990Oct9.230928.27552 at arp.anu.oz.au> peterf at arp.anu.oz.au (Peter Fletcher) writes:

> [ Gripe about float-to-int conversion ]
> I don't think this policy is in any of the C specifications, but it occurs
> in all the C compilers I've used (sun, apollo, pyramid).  Does anyone know
> why ?

It is important to understand that, in type demotion, C doesn't round
either way; it simply eliminates that which it cannot use.

K&R chapter 2, pp. 41 & 42:

  Conversions take place accross assignments; the value of the right side
  is converted to the type of the left, which is the type of the result.
  [...]
  If x is float and i is int, then
	x = i
  and
	i = x
  both cause conversions; float to int causes truncation of any fractional
  part.

BTW, I doubt this is going to go away.  In the December 1988 Draft of ANS
X3.159-1989 (ANSI C), section 3.2.1.3 "Floating and integral":

  When a value of floating type is converted to integral type, the
  fractional part is discarded.  If the value of the integral part cannot
  be represented by the integral type, the behavior is undefined.

> I think with Suns and Apollos you can tell the floating point hardware
> to use a different rounding mode, but it seems that both methods are
> completely different and probably not compatible with anybody else.
> Is there a reasonably standard Unix way to do this ?

If you want rounding, you will have to do it yourself.  C won't do it for
you.
--

     Roberto Shironoshita      ||   Internet: shirono at ssd.csd.harris.com
      Harris Corporation       ||
   Computer Systems Division   ||   UUCP:     ...!uunet!hcx1!shirono
                               ||
DISCLAIMER: The opinions expressed here are my own; they in no way reflect the
            opinion or policies of Harris Corporation.



More information about the Comp.lang.c mailing list