home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / c / 18724 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  3.2 KB
  1. Xref: sparky comp.lang.c:18724 gnu.gcc.help:2787
  2. Path: sparky!uunet!olivea!charnel!sifon!thunder.mcrcim.mcgill.edu!mouse
  3. From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
  4. Newsgroups: comp.lang.c,gnu.gcc.help
  5. Subject: Re: How precise is preprocessor math? (I'm using gcc)
  6. Message-ID: <1992Dec20.235758.11774@thunder.mcrcim.mcgill.edu>
  7. Date: 20 Dec 92 23:57:58 GMT
  8. References: <EJH.92Dec15111402@khonshu.colorado.edu> <1992Dec18.104956.11433@flood.com>
  9. Organization: McGill Research Centre for Intelligent Machines
  10. Lines: 65
  11.  
  12. In article <1992Dec18.104956.11433@flood.com>, tom@flood.com (Tom Chatt) writes:
  13. > volpe@ausable.crd.ge.com writes:
  14.  
  15. >> And then the compiler evaluates it, or more likely, just the
  16. >> constant expression part of it. (It probably isn't likely that it
  17. >> evaluates sin(70) at compile time, but it's allowed to.)
  18. > The compiler is allowed to evaluate routine calls at compile time???
  19. > I think not!
  20.  
  21. In general, no; in the case of sin(), it is.  sin() (and the rest of
  22. the stuff in ANSI's spec) are fully specified; the compiler is allowed
  23. to know everything there is to know about them, including, in this
  24. case, that sin() computes a value that depends on nothing but its
  25. argument, and how to compute that value, and hence actually do so.
  26.  
  27. > Given that an arbitrary routine may be called repeatedly with a
  28. > constant argument without any guarantee that the return value will be
  29. > the same,
  30.  
  31. Right.  It's not allowed to do so except when calling routines it knows
  32. behave nicely, like sin().  (This all comes under the "as if" rule: the
  33. compiler is allowed to emit anything that behaves as if it were
  34. executed as written.  Since a conforming program cannot tell the
  35. difference between actually calling sin() at run-time and compiling the
  36. resulting value into the code, the compiler is allowed to do the
  37. computation at compile time.)
  38.  
  39. > If Chris Volpe was suggesting the more limited proposition that
  40. > certain standard calls, such as sin(), are "known" to the compiler,
  41.  
  42. Isn't that what was said?
  43.  
  44. >> (It probably isn't likely that it evaluates sin(70) at compile time,
  45. >> but it's allowed to.)
  46.  
  47. Nothing about evaluating any other calls at compile time.
  48.  
  49. > that's plausible, but still seems dubious.  "sin" is not a resrved
  50. > word in C, and nothing would prevent me from writing my own "sin()"
  51. > routine which did something completely different.
  52.  
  53. Since ANSI, it effectively is a reserved word, when it occurs as an
  54. identifier with external scope.  You can write you own sin(), yes,
  55. provided you declare it with file scope, and in that case, the compiler
  56. is not justified in constant-folding it.  (I think you may also have to
  57. either omit <math.h> or #undef sin; not sure.)
  58.  
  59. > Even if [...], there would still be different implementations, and a
  60. > compiler would be presumptuous to pick one for me.
  61.  
  62. Huh?  sin() computes the sine function.  The implementation is
  63. irrelevant; only the return value matters.  The compiler may use a
  64. completely different implementation from the run-time version, but *you
  65. can't tell*, because the return value is - must be! - the same.
  66.  
  67. > [T]he "sin" routine being used by the example above apparently
  68. > expects degrees.
  69.  
  70. If so, that's a bug in the program.  sin() is specced to take its
  71. argument in radians.
  72.  
  73.                     der Mouse
  74.  
  75.                 mouse@larry.mcrcim.mcgill.edu
  76.