home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / c / 3210 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  1.5 KB
  1. Path: sparky!uunet!world!ksr!jfw
  2. From: jfw@ksr.com (John F. Woods)
  3. Newsgroups: comp.std.c
  4. Subject: Re: (long) x and (long) floor(x)
  5. Message-ID: <20095@ksr.com>
  6. Date: 14 Dec 92 17:48:10 EST
  7. References: <1ghtanINNcf9@cs.tut.fi>
  8. Sender: news@ksr.com
  9. Lines: 25
  10.  
  11. pjh@cs.tut.fi (Haavisto Petri) writes:
  12. >I just spent several hours debugging a simple program and before
  13. >crying Compiler Bug I would like to make sure that there is one.
  14. >I don't have the standard, but it seems clear to me that given an
  15. >expression of type double with a positive value, the following
  16. >should always be true:
  17. >        (long) (expression) == (long) floor(expression)
  18. >Does the standard guarantee this or is there a loop hole that has to
  19. >do with finite precision arithmetic and which allows the compiler to
  20. >do what it chooses?
  21.  
  22. The most obvious thought is:  do you have a proper prototype for floor()
  23. in scope at that point?  If not, you can expect random results.
  24.  
  25. The second most obvious thought:
  26. "If the integral part of the double cannot be represented by the integral
  27. type, the behavior is undefined."  So, if the expression's value is 5.0E+9
  28. on a system with 32-bit longs, then acceptable runtime behavior would include
  29. growing long red tentacles and slapping you silly, or returning the current
  30. time, or whatever (especially including calculating two different numbers,
  31. and there are plausible reasons why it could).
  32.  
  33. If floor() is in scope and properly declared, and the expression is in the
  34. range of the representation of long, then you have a compiler bug (which 
  35. will surprise no one :-).
  36.