home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / arch / 8958 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  1.5 KB
  1. Path: sparky!uunet!mcsun!uknet!daresbury!doc.ic.ac.uk!ibmassc!yktnews!admin!flu!marc
  2. From: marc@watson.ibm.com (Marc Auslander)
  3. Newsgroups: comp.arch
  4. Subject: Re: 32 => 64 Transition
  5. Message-ID: <MARC.92Aug19170300@marc.watson.ibm.com>
  6. Date: 19 Aug 92 22:03:00 GMT
  7. References: <340@moene.indiv.nluug.nl> <1992Aug08.165832.114442@cs.cmu.edu>
  8.     <1992Aug11.125326.16719@email.tuwien.ac.at> <id.UHAS.9TA@ferranti.com>
  9. Sender: news@watson.ibm.com (NNTP News Poster)
  10. Organization: IBM T.J. Watson Research Center, Hawthorne, New York
  11. Lines: 20
  12. In-Reply-To: peter@ferranti.com's message of 12 Aug 92 14:46:45 GMT
  13. Disclaimer: This posting represents the poster's views, not necessarily those of IBM
  14. Nntp-Posting-Host: marc.watson.ibm.com
  15.  
  16. The intent of ANSI C appears to be that int is the "natural"
  17. arithmetic of the machine.  This is reflected in the integer promotion
  18. rules, which promote to int but NOT to long.  Thus,
  19.  
  20.         int i,j;
  21.         long k;
  22.         k=i+j;
  23.  
  24. is defined to do its arithmetic in int, producing an int result, and
  25. then convert to long at the assignment.  If i+j overflows (as int) the
  26. results are undefined.  The idea clearly is that compilers shouldn't
  27. be forced to use the possibly less efficient long arithmetic on ints.
  28. Only by making int 64, or by changing the role of int in defining the
  29. way expressions are evaluated, can we avoid this and other anomalies.
  30.  
  31. --
  32.  
  33.  
  34. Marc Auslander       (IBM)<marc@marc.watson.ibm.com>      914 784-6699
  35.                      (Internet)<marc@watson.ibm.com>
  36.