home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / c / 13708 < prev    next >
Encoding:
Internet Message Format  |  1992-09-15  |  2.3 KB
  1. Xref: sparky comp.lang.c:13708 sci.math:11522 comp.lang.misc:3092 comp.lang.fortran:3578 comp.std.c:2635
  2. Path: sparky!uunet!stanford.edu!rock!concert!duke!dsb
  3. From: dsb@duke.cs.duke.edu (D. Scott Bigham)
  4. Newsgroups: comp.lang.c,sci.math,comp.lang.misc,comp.lang.fortran,comp.std.c
  5. Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
  6. Message-ID: <716597823@romeo.cs.duke.edu>
  7. Date: 15 Sep 92 22:57:04 GMT
  8. References: <a_rubin.716225408@dn66 <1992Sep12.164915 <1992Sep15.043224.27920@nntpd.lkg.dec.com>
  9. Followup-To: comp.lang.c
  10. Organization: n. Arrangement in an orderly or logical fashion.  See "miracle".
  11. Lines: 41
  12.  
  13. From the Holy Book of <1992Sep15.043224.27920@nntpd.lkg.dec.com>
  14.   as spake by diamond@jit.dec.com (Norman Diamond) :
  15.  
  16. >In article <1992Sep12.164915.10734@jarvis.csri.toronto.edu> flaps@dgp.toronto.edu (Alan J Rosenthal) writes:
  17. >>a_rubin@dsg4.dse.beckman.com (Arthur Rubin) writes:
  18.  
  19. >>>>>>    int a, b;   long c;
  20. >>>My interpretation (from reading K&R 2) would be that c = a * b should be
  21. >>>equivalent to c = (int)(a * b).
  22.  
  23. >Mr. Rubin,
  24.  
  25. Well, I'm not he, but your comments made me curious.
  26.  
  27. >           please state which section of the standard requires this.
  28. >If you cannot, then please at least quote the text in K&R 2 that led you to
  29. >this interpretation, so that we can see if K&R 2 has a bug that would be
  30. >worth recommending for correction and/or warning about.
  31.  
  32. Section A7.6, "Multiplicative Operators", states that "The usual
  33. arithmetic conversions are performed on the operands, and predict the
  34. type of the result."  Since a and b are both int's, the arithmetic
  35. conversions (described in section A6.5) predict that (a * b) should be as
  36. well.
  37.  
  38. >>Indeed it is, but if that cast-to-int were to overflow you would get undefined
  39. >>behaviour on that account.
  40.  
  41. >No, cast-to-int does not overflow.  It has a defined result.
  42.  
  43. Careful, this is _signed_ int we're talking about here.  According to
  44. section A6.2, "Integral Conversions", "When any integer is converted to
  45. a signed type, the value is unchanged if it can be represented in the
  46. new type and is implementation-defined otherwise."
  47.  
  48.                         -sbigham
  49. -- 
  50. Scott Bigham                   | The opinions expressed above are
  51. dsb@romeo.cs.duke.edu          | (c) 1992 Hacker Ltd. and cannot be
  52. bigham@hercules.acpub.duke.edu | copied or distributed without a
  53.     (but not for long)         | Darn Good Reason(tm).
  54.