home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / c / 3284 < prev    next >
Encoding:
Text File  |  1992-12-30  |  3.0 KB  |  69 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!spool.mu.edu!umn.edu!csus.edu!netcom.com!rfg
  3. From: rfg@netcom.com (Ronald F. Guilmette)
  4. Subject: Re: Overflow in constant expression (was: Standard conformance and GCC 2.3.3)
  5. Message-ID: <1992Dec30.093906.24206@netcom.com>
  6. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  7. References: <1992Dec30.011211.11409@netcom.com> <1992Dec30.075041.10907@sq.sq.com>
  8. Date: Wed, 30 Dec 1992 09:39:06 GMT
  9. Lines: 58
  10.  
  11. In article <1992Dec30.075041.10907@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:
  12. +
  13. +> #2)  GCC fails to detect the error in the following code, even when the
  14. +>      -pedantic-errors option is used.
  15. +> 
  16. +> unsigned long overflow = LONG_MAX + 3; /* ERROR */
  17. +
  18. +I presume this is being called erroneous because of the constraint:
  19. +
  20. +#  Each constant expression shall evaluate to a constant that
  21. +#  is in the range of representable values for its type.
  22.  
  23. Yes.
  24.  
  25. +in section 3.4 (ANSI) / 6.4 (ISO).  However, 3.4/6.4 also says:
  26. +
  27. +#  The semantic rules for evaluation of a constant expression
  28. +#  are the same as for non-constant expressions.
  29. +
  30. +This presumably includes the assertion in 3.3/6.3:
  31. +
  32. +#  If an "exception" occurs during the evaluation of an expression
  33. +#  (that is, if the result is not mathematically defined or not in
  34. +#  the range of representable values for its type), the behavior
  35. +#  is undefined.
  36. +
  37. +Since the constraint on the constant-expression applies to the *result*
  38. +of evaluating it, but the undefined behavior due to overflow applies
  39. +*during* the evaluation, I think "undefined behavior" wins.
  40.  
  41. Well, you're wrong.  x3j11 has already ruled on this exact issue. In
  42. Technical Information Bulletin #1, request for interpretation #31
  43. (and its response) make it quite clear that as fas as x3j11 is concerned,
  44. the expression (LONG_MAX + 3), when appearing in a context requiring
  45. a constant expression, is a constraint violation.  Interestingly enough,
  46. it is also x3j11's interpretation (or so I have been led to believe)
  47. that the expression (ULONG_MAX + 3) does *not* violate any constraint!
  48. (But that's an entirely separate issue.)
  49.  
  50.  
  51. // Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
  52. //
  53. //      "On the one hand I knew that programs could have a compelling
  54. //       and deep logical beauty, on the other hand I was forced to
  55. //       admit that most programs are presented in a way fit for
  56. //       mechanical execution, but even if of any beauty at all,
  57. //       totally unfit for human appreciation."
  58. //                                              -- Edsger W. Dijkstra
  59. -- 
  60.  
  61. // Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
  62. //
  63. //      "On the one hand I knew that programs could have a compelling
  64. //       and deep logical beauty, on the other hand I was forced to
  65. //       admit that most programs are presented in a way fit for
  66. //       mechanical execution, but even if of any beauty at all,
  67. //       totally unfit for human appreciation."
  68. //                                              -- Edsger W. Dijkstra
  69.