home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / c / 3206 < prev    next >
Encoding:
Text File  |  1992-12-14  |  4.1 KB  |  102 lines
  1. Path: sparky!uunet!crdgw1!rdsunx.crd.ge.com!bart!volpe
  2. From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Is INT_MAX<<1 defined?
  5. Message-ID: <1992Dec14.180046.2022@crd.ge.com>
  6. Date: 14 Dec 92 18:00:46 GMT
  7. References: <1992Dec1.050540 <1992Dec8.1 <Bz35no.J6M@jrd.dec.com> <8322@charon.cwi.nl> <Bz8MtG.479@jrd.dec.com>
  8. Sender: volpe@bart (Christopher R Volpe)
  9. Reply-To: volpe@ausable.crd.ge.com
  10. Organization: GE Corporate Research & Development
  11. Lines: 88
  12. Nntp-Posting-Host: bart.crd.ge.com
  13.  
  14. In article <Bz8MtG.479@jrd.dec.com>, diamond@jit533.jit.dec.com (Norman Diamond) writes:
  15. |> In article <8322@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
  16. |> >What it comes down to is that << is not a mathematical operation, there
  17. |> >is nothing in mathematics that tells us that 16384 << 1 equals 32768.
  18. |> 
  19. |> Additional non-mathematical operations:
  20. |>   ++ (prefix and postfix)
  21. |>   -- (prefix and postfix)
  22.      
  23.   The definition of their side effect is perfectly mathematical. It computes
  24. sum or difference, and therefore can overflow.
  25.  
  26. |>   [] (subscript, C definition using pointers)
  27. |>   () (function call, C definition using pointers)
  28. |>   () (cast)
  29. |>   unary  &  *  !
  30. |>   unary  ~  on a value that is not a single bit
  31. |>   binary /  on integral values where the mathematical quotient is not integral
  32. |>   binary .  ->  sizeof  %  &  ^  |  &&  ||  =  *=(etc.)  ,
  33.  
  34. Moot point, since none of these can generate an arithmetic overflow due to
  35. a result not fitting. The "op=" operators are and exception, and I consider
  36. them to be in the same category as "++" and "--", i.e., their side effects
  37. are perfectly mathematical, and that's what can overflow. 
  38.  
  39. In a nutshell, mathematical operators can overflow, non-mathematical
  40. operators cannot.
  41.  
  42. |> >    Where in the standard does it tell
  43. |> >    us that for signed (16 bit) int 16384, 16384 << 1 is 32768?
  44.  
  45. It doesn't. It tells us that the bits are shifted. So look at the bits
  46. the way your machine does, and that's what the value is.
  47.  
  48. |> 
  49. |> I think the standard is unclear enough to recommend an interpretation ruling.
  50.  
  51. Yeah, ok.
  52.  
  53. |> However, for comparison, for unsigned types, the standard says explicitly
  54. |> that the value of the result is a mathematical multiplication followed by
  55. |> a mathematical modulo reduction -- if it were a representation multiplication,
  56.  
  57. That statement is completely unnecessary. That simple fact can be derived
  58. from the properties of unsigned integers.
  59.  
  60. |> the modulo reduction would have been a no-op and would not have been stated.
  61.  
  62. No one is claiming that it is a representation multiplication. The standard
  63. is simply clarifying the behavior by saying (quite unnecessarily) that
  64. a *representation* *shift* behaves like a *mathematical* *multiplication*
  65. followed by modulo reduction for unsigned types, the way mathematical 
  66. multiplication is always followed by modulo reduction for unsigned types.
  67.  
  68. |> 
  69. |> >    Is an implementation not allowed to define it as -32768?  Or whatever?
  70. |> 
  71. |> Implementations are allowed to define what happens when signed results don't
  72. |> fit in the corresponding types.  They aren't REQUIRED to, that's all.
  73.  
  74. True. But it is not clear at this point that it's possible (more
  75. precisely, that it's meaningful to say) that a shift result can not fit
  76. in the corresponding type.
  77.  
  78. |> 
  79. |> >    But in all there is no definition in *mathematics* for this operation.
  80. |> [...]
  81. |> >The bottom-line is that shifting is not a mathematical concept, [...]
  82. |> 
  83. |> That didn't prevent a ton of other C operations from being defined on
  84. |> mathematical values.  Actually maybe the standards committees can start
  85. |> to get an idea of just how unpopular this stunt is.  However, that is what
  86. |> they did, following the path of other language committees.
  87.  
  88. Again, there is never a danger of the results of such operations 
  89. causing arithmetic overflow. Since none of the other non-mathematical
  90. operations can cause this, why should bit shifting?
  91.  
  92. |> --
  93. |> Norman Diamond       diamond@jit081.enet.dec.com
  94. |> If this were the company's opinion, I wouldn't be allowed to post it.
  95. |> "It's been a lovely recession."
  96.  
  97. -- 
  98. ==================
  99. Chris Volpe
  100. G.E. Corporate R&D
  101. volpecr@crd.ge.com
  102.